Thanks for the insights Ian.

Can you explain to me what policy would better suit your definition of open source?

As far as I understand this paragraph is the qualifier:
"except that this license does not apply to any Licensee Applications that you make available to the public under the GNU General Public License version 2.0."

It's set up to perpetuate the openness; so long as you keep your Chumby "Licensee Applicaiton" open source then no one, not even Chumby inc. owns the creation.

Actually, I'm not particularly interested in open source as a value for Chumby. I think there are benefits that derive from it, but in this case it's the notion of an "open platform" that interests me. An open platform is something that one can build for/upon and do with as he or she likes: sell, give away, open source, GPL, etc. It's important not to confuse "open" and "open source." And furthermore, GPL is a very particular kind of open source.

In particular, I'm disappointed that Chumby uses the Apple I/][ as a comparison, since a large variety of both free and commercial software arose from that platform.

Ok, interesting. So as an open platform any derivative 'licensee applications' should be owned exclusively by the person who created them? I'm not sure if I'm parsing the legalize correctly, but it does say "non-exclusive" rights for Chumby Inc. So you still own the app you create for the Chumby platform. Is that wrong?

This is an interesting conversation, so I invited the company to come chat about it on a topic over on Satisfaction: http://getsatisfaction.com/chumby/topics/how_open_(_open_source)_is_chumby
Hopefully they'll come along soon and let us know where they stand.

Thanks for bringing this up!

The open source exception is really kind of bizarre, since it's an exception from the "we own your work" for precisely one license, the GPL v2.0. That still leaves out large portions of the open-source world, like anyone using one of the Creative Commons licenses (cc-by, say), or heck even the forthcoming GPL v3.0.

It seems kind of ad-hoc, so it might be what Ian was surmising, that they had to (or at least thought they had to) allow a GPL v2.0 exception due to using GPL v2.0 code themselves.

I could imagine in theory a company actually having an open-source-centric strategy, saying something like: Here's our platform, you can have full specs and do whatever you want on it without our permission, as long as you open-source the result. Then maybe they'd allow proprietary development for a fee, or not at all, or under terms such as these. That might satisfy the free-software/open-source world, though as Ian points out it'd still be a far cry from the Apple I/II world. But in any case that doesn't really seem to be their strategy; the GPL exception looks like a afterthought buried in the fine print rather than the core of anything.

Yup, it's non-exclusive. And the creator still "owns" the content, but what's the point of ownership if you've also granted perpetual rights to another party? That's still pretty squirrely if you ask me. When I buy a Nokia N95 and sign up to get a Symbian SDK, or install XCode on my Mac, or VisualStudio Express on my PC, Nokia and Apple and Microsoft don't make claims to ANY rights in what I create for their systems. Historically, that's just good business: platform companies build, market, and sell platforms and provide tools and reasons for developing for it. Maybe the assumption is that Chumby is just a "hobbyist" platform, but should being a hobbyist mean that Chumby Inc. has the rights to market what I make just because I used their SDK?

Sheesh. Now I'm really curious what they are thinking, even other platforms, which are commonly viewed as hobbyist are more open than that (http://makingthings.com/, processing.org etc.).

This is bunnie from Chumby Industries posting a comment.

Ian, thanks for the insightful discussion. Our license is confusing and we probably need to take another look at it.

First, let's be clear on our intention: you do own and retain rights to your inventions.

The language of section 3.3, in practice, does not apply to any of the software provided with the chumby device; it's broadly drawn and directed primarily at the hardware, where the definition of a derivative work is subtly different. For software derivative works, section 3.2, "Separately Licensed Code", effectively overrides any of our terms and conditions when it comes to code that is, say, GPL or BSD licensed. Since almost all the code in the chumby device, save the Flash player, is Open licensed, you retain all the traditional, well-understood rights that apply. In particular, 3.3 concludes with an explicit exemption for code that you make available under GPL2 (I don't know exactly why it was drafted specifically to mention only the GPL2). Also, 3.3 opens with the statement "You retain your ownership rights in your innovations." Essentially, a standing open license on code wins, and if you create a derivative work of that we can't replace it. We also believe that we have put proper GPL2, BSD, etc. headers in all the applicable source files; if they are missing, then we'd appreciate a note so that we can fix that.

Also, from the perspective of our "SDK", that's a bit of a misnomer, and it seems to be the root cause of your confusion. We don't really have an "SDK" comparable to say, Visual Studio. I mean, there's a link to the GNU toolchain on our Wiki, but that doesn't give us rights to anything you do with GCC! That's separately licensed code. I think the intention of the "SDK" mention is to give us the ability to roll in any improvements you might make to our custom bits of the chumby OS, for example. If someone were to tweak our custom boot scripts, for example, to be more efficient or to fix bugs, then that's something we want to be able to incorporate into our main branch. One of the guiding principles of open software is that any improvements to the software can be adopted by everyone else, including the originator of the software. We probably do need to clean up the SDK language, because it has proven to be confusing.

From the hardware side, the intention of the license is to enable innovators (big and small) to hack, modify, and accessorize their chumbys, and for these innovators to profit from the fruits of their labors. Nothing in the license prevents one from say, creating a rechargable battery accessory for the chumby device, and selling this accessory for profit. However, if we decide later on to make a battery accessory for the chumby device ourselves, sections 3.1 (give) and 3.3 (take) work together to effectively create an automatic cross-license that enables us to do this. To see why the cross-licensing is important, consider the case that someone were able to hypothetically patent the idea of a chumby with a battery. Without the automatic cross-license, we might be unable to create our own version of a battery pack. Remember, users of our HDK are given an automatic license to Chumby's IP, so the relationship is reciprocal. The license effectively bypasses potential patent disputes within the Chumby hardware ecosystem, while allowing patents to exist as a defense from another company attempting to assert their portfolio on the Chumby hardware ecosystem (as is currently happening to the Linux ecosystem). On the other hand, Chumby does retain rights to its branding, so if you did make an accessory for the chumby device, you can't put our logo and name on it without a separate agreement with us.

If I were to beef on anything in the license, it would be on the point that we don't give you the right to manufacture a chumby device. However, we are (or at least I am) amenable to the idea of other people pitching in to build hardware--building a hardware supply chain is difficult and risky, so the diversity that cloners bring are an important part of a healthy ecosystem. Therefore, cloners are encouraged to come talk to us and work out a separate license. We do this so we can better support the installed base of chumby hardware as the hardware design evolves. Without this, some users who own cloned hardware could end up "stranded" as we add and deprecate features from our version of the system, and we want to avoid the scenario where owners of a cloned chumby wake up in the morning to find their device bricked due to a change in the overall system software.

Thanks for the insightful discussion. Please do email me directly at chumby (I'm bunnie) with any further clarifications or suggestions for improvements. Open hardware is a bit of a new area, so we wrote this new license. There's always bugs and differences of opinions to be found in new stuff. My hope is that the license enables hardware developers to be more efficient (by skipping NDAs and tedious reverse engineering efforts), and that developers profit and benefit from our platform through making and selling their innovations. From the software standpoint, I hope developers think of chumby as pretty much any other open development project on an embedded platform, such as Xbox Linux or the Linux on Dbox2 projects.

bunnie, thanks for taking the time to leave these comments. I want to read them and consider whest questions I might have in response, but in the meantime I simply wanted to express my appreciation for posting them here.

bunnie --

As I mentioned before, I want to thank you again for replying there and inviting this communication. You say your license is "confusing" and I agree, so I hope you'll not only respond to these questions, but also consider actually changing the license itself if appropriate. I have some comments and questions in response to your post here.

First, let's be clear on our intention: you do own and retain rights to your inventions.

I can see that, but only a fool or a novice would care about ownership if he also granted a perpetual, royalty-free license to his works. This point is a red herring.  

For software derivative works, section 3.2, "Separately Licensed Code", effectively overrides any of our terms and conditions when it comes to code that is, say, GPL or BSD licensed.

I can see that section 3.2 satisfies the need to follow the letter of the GPL and BSD licenses for derivative works. However, what about code for interfacing with other aspects of the device? It is never revealed in the license or any HDK/SDK documentation before it (there is really no documentation before the license) about what is or isn't provided outside such licenses. Furthermore, just because a toolkit or SDK you built might itself be licensed under GPL does not mean that a software application that makes use of that library, which is presumed to be installed on all Chumbys, would be bound by the terms of the GPL; I could, in other words, sell such work for profit. But only if you give me the SDK in the first place. I think you'll agree that paragraph 3.2 therefore doesn't cover my concerns, at all.

We don't really have an "SDK" comparable to say, Visual Studio. ... I think the intention of the "SDK" mention is to give us the ability to roll in any improvements you might make to our custom bits of the chumby OS, for example.

Your license explicitly references an SDK, which is defined as "collectively, the software code, software reference documentation, and other software-related materials provided by Chumby under this Agreement." This means anything not provided under GPL on your wiki. The user has the expectation, based on the existence of the agreement, which is called SDK/HDK agreement, and the explicit mention of an SDK, and the granting of "a license to use the Chumby SDK," that Chumby will in fact be providing an SDK as a part of the agreement. If you don't actually have an SDK, then you should strike all references to it from the agreement. Someone might construe it as bad faith. 

I think the intention of the "SDK" mention is to give us the ability to roll in any improvements you might make to our custom bits of the chumby OS, for example.

Paragraph 3.3 covers "Licensee Applications," which are defined in the agreement as "any software that consists of (a) Licensee-created modifications to or derivative works of the Separately Licensed Code or (b) Licensee-created programming code integrated with the Separately Licensed Code, or both." This clearly covers software that is not derivative of GPL code but that makes calls to it. So your intention described above is much narrower that what the HDK/SDK license actually supports.

One of the guiding principles of open software is that any improvements to the software can be adopted by everyone else, including the originator of the software.

Open source software is different from an open platform. When you compare Chumby to the Apple ][, you imply that it is offering the user free reign similar to that platform, which supported all manner of modifications and additions that Apple demanded no control or rights to. You should take care not to conflate these concepts. 

From the hardware side, the intention of the license is to enable innovators (big and small) to hack, modify, and accessorize their chumbys, and for these innovators to profit from the fruits of their labors. Nothing in the license prevents one from say, creating a rechargable battery accessory for the chumby device, and selling this accessory for profit. However, if we decide later on to make a battery accessory for the chumby device ourselves, sections 3.1 (give) and 3.3 (take) work together to effectively create an automatic cross-license that enables us to do this. 

Once again I draw your attention to the letter of the agreement, not to your own personal intentions or interpretations about its meaning. 

To see why the cross-licensing is important, consider the case that someone were able to hypothetically patent the idea of a chumby with a battery. Without the automatic cross-license, we might be unable to create our own version of a battery pack.

I am not experienced in patents, but I am fairly certain this is a false analogy. Someone could not patent a Chumby with a battery without violating your patent(s). However, they could patent a device or method for providing battery power to a portable device. If this method happened to work with a Chumby, then only in cloud cuculand would it be reasonable for you to expect to get an automatic license to their IP. Unless of course they decide to agree to your inane HDK/SDK agreement.

Remember, users of our HDK are given an automatic license to Chumby's IP, so the relationship is reciprocal.

The license you refer to provides only the right to modify your own device or distribute the device without modification. Hardly reciprocal. 

Finally, I have a question unrelated to licenses. Your return policy states that "A $20.00 open box fee will be assessed on any opened hardware or accessory, and damage and missing part restocking fees may apply." I ordered my Chumby before discovering my distaste for your license agreement. I have since received it and I am deciding whether I want to send it back. However, the device is packaged in a foam wrapper sealed with Chumby-emblazoned sticker. If I open this to simply look at the device (which is not visible in any way as it ships, for example to see the size of the screen or the quality of its manufacture), and if I then return it, will I be charged the fee? 

Thanks again for your time and interest. 

Hi Ian,

Thanks for your thoughtful response.

Of course, we want to make sure that potential developers are comfortable working within the Chumby open infrastructure, so it's good that you, along with other developers, have contacted
us and expressed concerns.

We had a discussion today about the issue and it turns out many have misinterpreted the "SDK" terminology in the license. Since most of our code in our device is GPL/BSD/MIT/etc. licensed anyways, we are planning on striking the use of the term "SDK" from the agreement altogether, since we have no formal SDK and the codes' native open licenses are what really matter.

In other words, developing code for the chumby is just like developing code for any other open embedded platform, but of course code such as the Adobe Flashplayer remains closed because it's licensed to us as a closed piece of code and we are legally bound by prior licenses to keep it closed.

This should address most of the concerns that you have about the software and the use of the term SDK.

With respect to the hardware, I have a couple of clarifications I need to make.

First, I used an inaccurate analogy with the battery pack accessory. The definition of a derivative work for hardware is different from some of the opinions that exist about software derivative works. For example, some GPL advocates claim that linking two pieces of code together creates a derivative work. In the case of hardware, installing a USB device into a USB slot
on the chumby does not create a derivative work. The device in the USB slot is a separate piece of work and is not "tainted" by being plugged into a chumby device. Rather, the appropriate analogy for a derivative work is if someone were to take our schematics and board layouts from the HDK, modify them, and create a daughtercard that incorporates a battery. In other words, a plug-in accessory is generally separate work and has nothing at all to do with the chumby HDK license.

With the language of the license, the result of modifications to the core hardware is essentially "share-aliked". Significantly, if you don't agree to our HDK license, you are still free to reverse engineer the hardware in a "cleanroom", and the results of your work are not bound by our HDK. This is effectively the situation anyways today with most consumer products, so really what the chumby HDK does is enable you to focus on innovation instead of the tedium of reverse engineering. And, as mentioned before, the chumby HDK encourages companies that want to mass-manufacture chumbys to contact us to get a license, and hopefully the process will be painless. The overly-broad definition of manufacture always bugs me, because I want to make sure that say, a professor looking to adapt a chumby to be a controller for a class on robotics would not be deterred in any way to do this. Doing this for a class of a hundred students isn't the kind of manufacturing we're referring to in the HDK agreement, but paranoid legal interpretations could construe it that way. This is also something that will need fixing or clarification in the agreement.

Second, you are correct that the analogy with the Apple ][ isn't quite correct. There is in fact a landmark case where Apple sued Franklin Computer corporation for using its schematics and source code to make the Franklin Ace 100. Chumby differs from Apple in that while we provide the schematics and the source code, we also strive to explicitly delineate what rights are granted in the distribution of these items so that hopefully nothing ever has to go to the courts. So, I do think that distributing an open HDK to our userbase will enable users to create a healthy, thriving ecosystem of accessories, and in fact users can own their plug-in accessories as they owned the plug-in cards that they invented for the Apple ][, although I do hope that these innovators will be inspired to share their designs in an open fashion.

Even better, users are explicitly allowed to take our schematics and do something with it. I've often thought it would be neat to take the Apple ][ schematics I have posted on my wall and put them into an FPGA, but the fact of the matter is if I did that and posted an article about it, I would be in direct violation of the copyrights that protect these schematics and ROMs, and the last thing I need is Apple suing me. Not in the case of Chumby, as the HDK license allows you to do just that!

Therefore to boil things down to a few simple points:

You, like others who have contacted us, are correct: the SDK is a misnomer, and this should and will be fixed; we open-license all the code that we are legally allowed to open-license, and these traditional open licenses govern the rights of these works.

The HDK's boundary is restricted to the hardware definition of a derivative work, which means only items made with the direct assistance of the gerbers, schematics, and other blueprints of the chumby device. It generally does not extend to plug-in accessories, so that area remains "business as usual", although we do hope that innovators will voluntarily open-license their accessories under a similar agreement.

In the context of modifications to the chumby device itself, the HDK license attempts to extend the concept of "share-alike" (as described by the creative commons license) to the chumby device. The core concept of Openness derives from the old story of the punched-tape drawer next to the mainframe: in this drawer, programmers would store their code, and every programmer who used the machine was free to use these programs. When an improvement was made to a program, a new tape was punched and added to the drawer. Thus, everyone, including the original program writer, was able to enjoy in the benefits of the community's improvements.

Unlike software, hardware fits well into the patent model, as you can protect processes, machines, articles of manufacture, and compositions of matter with patents. Therefore, the HDK license has to tackle the patent issue head-on with the language about cross-licensing, in addition to tackling the copyright issue
which is the best-understood protection for software (as you know, software patents exist but they are a hotly contested subject).

Therefore the net result of the license, once the SDK portion is stripped out, I *hope* is to create the equivalent of the punched-tape drawer for the chumby device hardware: you are free to take the blueprints of the chumby, improve it, and then when you are done, drop the improved blueprints back in the drawer for everyone to benefit from.

I think probably the next best step after these license revisions is to see what the community ends up doing with the chumby device and seeing how the license fits the people. In the end, even the friendliest agreements turn sour if either of the parties have a heart for litigation--you see this every day in family court. Likewise, no agreement has any real meaning until it's enforced, and ultimately it boils down to who you are dealing with. We hope that by making the effort and investing the money to create an open and friendly license, you will regard that as a favorable token of our intent.

If you just don't trust the people of Chumby, then even the most liberally worded license agreement should not lull you into a sense of safety. Besides, you can always disagree with the HDK, use none of our materials, and reverse engineer our designs. However, if you trust that Chumby wants to create an open community, then participate in our experiment to extend the concept of openness into the hardware world: go forth, and innovate -- and share.

As for your returned unit, I understand that it has all been worked out favorably for you with our customer service department; we do incur real costs in materials, labor and testing to refurbish returns, so we appreciate your patience and understanding. Fortunately, I've already found a good home for your unit, so please do send it back!