Pre-requisite: Choosing a License Model for the Robotics System

[Sienna]

Before we go choosing packages for this that and the other thing, we might want to discuss licensing of all this (what Matt calls the TRS)

Personally, I expect the license to be "open source". This has some restrictions if anyone tries to use the robotics system commercially, but as I am willing to work on this as a part time volunteer, that doesn't bother me. It might bother other people if they expect to recieve $$$ for this.

Initially, it would be my opinion to make the robotics system under a GPL license. Why would I want to do that? Because it opens up the biggest breadth of other open source software to play with.

For instance, I would like to use Qt, as it is cross platform, and has a whole lot of libraries for doing things like reading XML and sending stuff on a network, in addition to making fancy windows. For me to use Qt, the open source license is the only way I can get it, because I don't have a few thousand to buy myself a closed source license.

What are everyone else's thoughts?

[Adrenalynn]

As long as it's modular with the "glue" between modules licensed appropriately, it doesn't matter. Don't like the license on one piece? Tear it out and replace it with a license you do like.

[Wingzero01w]

Im confused, what robotics system are you trying to license? Are you talking about something like the SES?

[Alex]

I'm not sure what everyone discussed with Matt as far as what language will be used, but how do licenses work with .NET applications if there is no intention of making money off of it? I thought how they worked is as long as there is no revenue generated from the application then you can use .NET.

Honestly, it doesn't matter much what language the core TROM is developed in, because since it's going to be using web services to "hook" onto, you can use any language that supports working with web services. The algorithm, sensor and controller libraries can be totally different languages (provided they can work with web services).

Again, I have no idea what was discussed, so if I'm way off here on something, let me know.

[Adrenalynn]

I may be way off base here, I haven't developed any commercial dotNet applications, but I thought that was environment-dependant?

If you use Express, you can't make money off of it. That make sense. But if I used my Enterprise Architect license and couldn't sell my developed product, I'd be pretty ticked-off. [shrug] Mickeysoft has always been kinda goofy in their licensing models, imho.

I think Sienna's concern may just be in exactly this area. OGRE is an open source rendering engine. It doesn't know or care about .Net (nor, IMHO, should we if we're looking for true cross-platform capability). If OGRE's license isn't compatible with .Net, there could be issues. The key (in my experience) is to keep all code from one module out of another module, building a third "glue" module under your own license to hold it together.

Still - at some point someone has to be able to monetize something. It's important to keep that in mind.

That said - I'm not a lawyer, and am unqualified to offer anything outside of an unqualified personal opinion. For legal questions, always consult a lawyer...

[Alex]

I may be way off base here, I haven't developed any commercial dotNet applications, but I thought that was environment-dependant?

.NET is environment dependent in most cases. However, with the advent of webservices (http://en.wikipedia.org/wiki/Web_services) all of this has changed.

I'm still learning about them so bear with me (read up on that Wiki for a better explanation), but what I understand is that web services allow us to write a .NET application, turn objects into XML files which we can access through a browser. Then, on the other end, using any language we want (so long as it can supports XML interaction), we can use GET & PUT commands to interact with any data we need from the object:)

This is much more efficient way of programming, because this makes the TROM (the main guts of the TRS) basically language independent provided of course the languages support interacting with XML files:D

What would be incredibly cool, and this may be the way that Web Services work now (again, still learning) is if we can serialize/deserialize XML files to/from objects. Although I'm not sure about how more/less efficient this would make the applications.

[Sienna]

Licensing matters so far as you want us to help you build things Alex.

I imagine the communication protocols are going to be something akin to RFCs, e.g., an open, published document under peer review maintained by a standards board. They won't be under any one person or companies control. Everyone is welcome to read the standard, and implement the same protocols. (as a syntactical note, please, its not 'web services', its a protocol)

Now, back to the licensing question. I was under the impression that Trossen Robotics is not staffed and funded to go develop the entire object model by themselves. If this is not true, I apologize.

Assuming that the first iteration of the robotics system is going to be built, by us, collectively as a group, the question I was trying to ask is "what license do we, collectively, want to develop the first iteration of the robotics system under?"

I personally will not contribute to a closed source project which I am not getting compensation for. So, I am asking the collective us to consider an open source license. (Licensing has no impact on language, so don't confuse the .NET stuff just yet.) Basically, what the open source motto is, is "publish your source code and let others download, modify, and redistribute it". This is the easiest way to attract un-paid help. Assuming we agree on the license type, then we have to agree on the actual words of the license. Lucky for us, there are a lot of example licenses out there. I pointed out a specific one I think that we should use, the GPL. Basically, the GPL says that "This code is free. However, if you modify it, you have to distribute your changes to this code as well. Also, any derived works that use this code must also fall under the GPL."

Once we decide on a license, then we can decide on a language. Again, if you want community to help develop this first pass of the model, you will need a common language to write in, and a common repository (such as subversion). I imagine that the .NET framework, or any languages (C#) or IDEs (Visual Studio) written by Mircrosoft are going to get some negative feedback. (But I could be wrong, there might be a lot of C# programmers out there interested in helping... I just won't be one of them.) The reason being is that Microsoft has a history of "Embrace, Extend, Extinguish". Which, from a business perspective, is great! But from an open standards or ethical perspective, sucks.

WingZero: http://www.trossenrobotics.com/tutorials/trossenroboticssystem.aspx

EDIT: I was wrong, there is such a thing as "web services".... ICK!

[Sienna]

On the "web services" front, I think it would be nicer to look at CORBA (http://en.wikipedia.org/wiki/CORBA) rather then something like webservices (e.g., SOAP)

[Alex]

I am totally open to any and all suggestions as to better ways of developing this system. I just hate and close up really quick when someone slams their fist on the ground and says this is how it's going to be.

That aside, let me try and dissect the main points...


Licensing matters so far as you want us to help you build things Alex. Sorry if you misunderstood me, but I never implied that I didn't think licensing mattered. It matters tremendously. I don't have any experience with licensing though, so I'm mainly depending on all of you to shed a little light (and light discussion) on this topic.

Now, back to the licensing question. I was under the impression that Trossen Robotics is not staffed and funded to go develop the entire object model by themselves. If this is not true, I apologize.
You're pretty much on target with this. Our "budget" so to speak for development really was never there in the first place.


I personally will not contribute to a closed source project which I am not getting compensation for. So, I am asking the collective us to consider an open source license.I don't think anyone including myself ever implied that we wanted a closed source project. That wouldn't make much sense since this is now turning into a community effort. I was always under the impression that we were going to open source the entire TRS.


As far as the languages to develop on, as I stated earlier, using web services it doesn't matter which ones we use because you have the ability to write all of the sections of the TRS in different languages provided of course they support the common XML standard.

Let me try and explain a little further:

There are four major sections of the TRS: the TROM (Trossen Robotics Object Model), Algorithm library, Sensor Library and Controller Library. This excludes the rendering portion that will be plugged into the TRS. The algorithm, sensor and controller library have not been written yet. The TROM (the core of the TRS, the class diagram that I sent you yesterday) has already been written. There needs to be some modifications to it though, because the way that it is developed now, it does trap users into using strictly .NET. I used an observer design pattern (unfamiliar? see here (http://en.wikipedia.org/wiki/Observer_pattern) and here (http://www.dofactory.com/Patterns/PatternObserver.aspx)). This was the only way that I could knew how to notify other areas of the TRS (algorithm, sensor & controller library) that changes occurred in the TROM. After the TROM was built, I learned about web services. By converting the observer design pattern structure over to web services, we are able to now develop the algorithm, sensor & controller libraries in any language we want, and still use everything in the TROM which is developed in C#.

I hope that cleared some questions up:D

[Alex]

Thanks for the link to COBRA. It sounds like a really interesting topic I need to look into a bit more:)

I'm totally open to better solutions than Web Services. That was just one solution that I found (specifically REST Web Services (http://en.wikipedia.org/wiki/Representational_State_Transfer) and SOA (http://en.wikipedia.org/wiki/Service-oriented_architecture)) that many companies are starting to convert over to. This sort of programming is all pretty new to me, so I'd love to hear other solutions.

[Sienna]

Ok, so we are in violent agreement, everything should be open source :P

I still would like to hear everyone's opinion on what license (the actual terms) we will be developing under. (as that will limit what libraries we can link or compile with)

For now, the object model can be .NET, as I think we all have windows pcs. However, sometime in the future, I imagine there would be a benefit in rewriting it so that people without windows can use this paradigm as well. (This also might be a non-Trossen activity too, after all, the whole schebang is supposed to be interoperable right :P)

Another paradigm we need to discuss is something called "Publish and Subscribe Services" (PASS). We use things like that at work. (I am not advocating or nonadvocating it... just another data point for discussion)

At some point too, I would also like to discuss the architecture as well. For instance, where do I plug in behaviors? Who is responsible for choosing which algorithm to run? I won't go into it now, but I think there are discussions to be had.

[Alex]

I have to say Sienna, CORBA sounds REALLY cool! I don't fully understand all of it, yet, but what I do understand, it sounds like it could very well work for the TRS.

It's funny, because it sounds very similar to what I understood of web services, except that it looks like it is more widely supported between languages.

CORBA (more precisely, GIOP) uses binary formats in order to transmit data. This is more efficient than a textual format (such as XML), since the amount of data to be transmitted is smaller and less processing has to be done to encode and decode data.Way cool:D:D

[LinuxGuy]

Before we go choosing packages for this that and the other thing, we might want to discuss licensing of all this (what Matt calls the TRS)

Personally, I expect the license to be "open source". This has some restrictions if anyone tries to use the robotics system commercially, but as I am willing to work on this as a part time volunteer, that doesn't bother me. It might bother other people if they expect to recieve $$$ for this.
If we can't deal with 100% (not 99.9%) platform independent Open Source, then I don't see much reason to even start this. I'm not going to write code for something that is going to be closed off in some way from people being able to use it for anything they want to use it for, including taking parts of it and creating something new. I do not want money to be made from what I do, and am tired of all the closed and otherwise proprietary solutions I have no access to.

I have other ideas that could plugin into something like we are talking about too, such as visual sequencing software.

Initially, it would be my opinion to make the robotics system under a GPL license. Why would I want to do that? Because it opens up the biggest breadth of other open source software to play with.
I don't mind as long as no part of this project is closed off from anyone, and no money is made directly from anything I do, as in none of my code winds up in a commercial product.

For instance, I would like to use Qt, as it is cross platform, and has a whole lot of libraries for doing things like reading XML and sending stuff on a network, in addition to making fancy windows. For me to use Qt, the open source license is the only way I can get it, because I don't have a few thousand to buy myself a closed source license.
I agree. I need to get back into learning how to use QT. I want to write some cross platform sequencing software at some point. It could potentially plugin and use OGRE for visualization.

Apologies if I seem a bit militant when it comes to licensing issues, but that sort of thing makes my head hurt and I do not enjoy having to deal with any of it.

8-Dale

[LinuxGuy]

As long as it's modular with the "glue" between modules licensed appropriately, it doesn't matter. Don't like the license on one piece? Tear it out and replace it with a license you do like.
Multiple licenses just complicate things and I really do not want to have to deal with that.

One License to Rule them All. :veryhappy:

8-Dale

[LinuxGuy]

Honestly, it doesn't matter much what language the core TROM is developed in, because since it's going to be using web services to "hook" onto, you can use any language that supports working with web services. The algorithm, sensor and controller libraries can be totally different languages (provided they can work with web services).
The .NET framework is not platform independent, so it must be ruled out for use here. There are quite a few platform independent frameworks that could be used if we are talking about web services, which I don't think we are at present. Web services are certainly something to consider and it would be desirable to have them, but as an added layer, not as an end all be all requirement for using any of this. Any web framework used must be unencumbered in any way and fit into the Open Source idea without problems.

8-Dale

[Alex]

If we can't deal with 100% (not 99.9%) platform independent Open Source, then I don't see much reason to even start this.I'm not sure where all this confusion about whether or not the TRS was going to be Open Source came from? From my understanding with talking to Matt just the other day, once we decided to make it a community effort, it turned into an open source project.:D

Matt and I intended it to be mostly an open source project even back when we were originally developing the TRS, but we put the project on hold. But once the community stepped in and was interested in bringing the TRS to fruition, we decided on 100% open source.

As far as platform independent, that was always our intention from the start. We never wanted the project to lock users down to any OS. We also wanted users to be able to use any language they wanted to interact with the TRS.

[LinuxGuy]

For now, the object model can be .NET, as I think we all have windows pcs. However, sometime in the future, I imagine there would be a benefit in rewriting it so that people without windows can use this paradigm as well. (This also might be a non-Trossen activity too, after all, the whole schebang is supposed to be interoperable right :P)
I have one PC that dual boots Windows XP and Linux. :veryhappy: I don't do Windows unless absolutely necessary. I'm still resisting doing any development in a Windows environment, so nothing I do gets platform specific. I prefer the libraries and such I choose to dictate what I can and can not do, rather than the environment I use for development.

Even with that, I am always curious about other tools and environments. I did just remove all the ancient 2005 MS tools and installed the new 2008 tools (Visual C# Express and Visual C/C++ Express), as well as the latest MSRS. This is not the environment I prefer to develop in, even though it's unfortunate MS has the money to afford developing and making such nice tools available free. It's all just another marketing gimick for them.

Another paradigm we need to discuss is something called "Publish and Subscribe Services" (PASS). We use things like that at work. (I am not advocating or nonadvocating it... just another data point for discussion)

At some point too, I would also like to discuss the architecture as well. For instance, where do I plug in behaviors? Who is responsible for choosing which algorithm to run? I won't go into it now, but I think there are discussions to be had.
I don't understand a lot of this yet, so please be gentle while I come up to speed. :veryhappy: I understand the basic ideas of this stuff, but have never actually worked with any of it.

8-Dale

[LinuxGuy]

There are four major sections of the TRS: the TROM (Trossen Robotics Object Model), Algorithm library, Sensor Library and Controller Library. This excludes the rendering portion that will be plugged into the TRS. The algorithm, sensor and controller library have not been written yet. The TROM (the core of the TRS, the class diagram that I sent you yesterday) has already been written. There needs to be some modifications to it though, because the way that it is developed now, it does trap users into using strictly .NET.
I think before we go to much further, we should replace .NET with something more appropriate for an Open Source robotics environment. It needs to be cross platform and usable from as many different languages as possible. I think for this whole thing to work and attract the most users/developers, it really can not have any software component tied in any way to a specific company. We all need to be on the same page, in the same environment, using the same software components (at least to start with). We can't be working with apples while somebody else is trying to plug an orange in.. :veryhappy: Something like .NET can be layered on later, as can other software unique to other platforms. The core must be the same though, and be Open Source and FREE in all respects, and not be encumbered.

8-Dale

[Alex]

The .NET framework is not platform independent, so it must be ruled out for use here.Yes, I agree. The intention was always to re-write the TROM in a platform independent language. Unfortunately, I don't have any experience with non .NET languages (a little Java, but not much), so I won't be able to help much with the programming aspect, only architecture.:(

There are quite a few platform independent frameworks that could be used if we are talking about web services, which I don't think we are at present. Web services are certainly something to consider and it would be desirable to have them, but as an added layer, not as an end all be all requirement for using any of this. Any web framework used must be unencumbered in any way and fit into the Open Source idea without problems.I'm definitely not saying that we must use Web Services, but we do need a way of handling communication between the four parts of the TRS using some sort of TCP/IP model. We want this system to be as flexible as possible and be able to handle future robotic applications, not just these smaller robots that we all deal with today.:D

[LinuxGuy]

Yes, I agree. The intention was always to re-write the TROM in a platform independent language. Unfortunately, I don't have any experience with non .NET languages (a little Java, but not much), so I won't be able to help much with the programming aspect, only architecture.:(
Every project needs a good architect. :happy: Any replacement we choose for .NET has to be flexible, be easy to write APIs for and in any lanuage, and be able to scale up well for more complex tasks. That's a pretty tall order, to be sure, but I believe what we need is out there.

I'm definitely not saying that we must use Web Services, but we do need a way of handling communication between the four parts of the TRS using some sort of TCP/IP model. We want this system to be as flexible as possible and be able to handle future robotic applications, not just these smaller robots that we all deal with today.:D
Most definitely! This project is not going to become a reality over night and is a very large undertaking. Scalability is very important. We don't want this to be limited to working well with just one type or class of robot either. I'm starting to catch the overall vision for this project now, and where I can visualize something, I can help bring it about.

8-Dale

[Alex]

I don't understand a lot of this yet, so please be gentle while I come up to speed.

you and me both Dale:) I don't know a thing about PASS. Sienna, do you have any good links that can explain it in laymans, or would you mind giving us a dumbed down version of what it's all about?


I think before we go to much further, we should replace .NET with something more appropriate for an Open Source robotics environment. It needs to be cross platform and usable from as many different languages as possible. I think for this whole thing to work and attract the most users/developers, it really can not have any software component tied in any way to a specific company. We all need to be on the same page, in the same environment, using the same software components (at least to start with).

I couldn't have said it better myself Dale:D

[Sienna]

If we can't deal with 100% (not 99.9%) platform independent Open Source, then I don't see much reason to even start this. I'm not going to write code for something that is going to be closed off in some way from people being able to use it for anything they want to use it for, including taking parts of it and creating something new. I do not want money to be made from what I do, and am tired of all the closed and otherwise proprietary solutions I have no access to.

Hehe, calm down Dale :P I think this will work.

What we are violently circling around I believe is the creation of three things:
1) A proposed architecture standard
2) A proposed interface standard
3) A sample, open sourced, implementation of the architecture in 1, communicating over the protocol defined in 2.

What this will not prohibit, is a commercial company coming along and implementing some piece of that architecture however they wish. The only requirements would be that they adhere to the
architecture in 1 (that is whatever pieces they wish to make perform the functions specified in the architecture), and that they communicate using the protocol defined in 2.

This is a good thing. Take for example a visualization library. Because we few volunteers have limited time and resources, we might make it only use solid colors for instance. However, a commercial company could come along, dedicate a lot of time and resources, and their visualization library does UV mapping, ray tracing, phong shading, what have you. Both products (the open source and commercial) could be used in the same place, because they both adhere to the same standards.

I believe Alex has already stated that he and Matt want to open source the whole .NET thing that they already wrote. It will of course have to be modified to adhere to whatever we decide the protocol is. But just because it is .NET does not mean that the rest of us have to use .NET ourselves. Because the protocol we define will be message passing of some sort, you will be free to write an algorithm library in C for instance, and it would communicate over a network to the .NET thing. For the moment, because we are all geeks, and all have multiple computers, I think this will work as a decent jumping off point. And then, at sometime in the future, we can work on re-implementing the object model.

[Adrenalynn]

Just because something is open source doesn't mean that someone can't make money from it.

[LinuxGuy]

Hehe, calm down Dale :P
Oh, OK, I'm calm. :happy:

What we are violently circling around I believe is the creation of three things:
1) A proposed architecture standard
2) A proposed interface standard
3) A sample, open sourced, implementation of the architecture in 1, communicating over the protocol defined in 2.
Which came first, the chicken or the egg? :happy: I think the basic architecture has been laid out pretty well so far. We need to adapt it to not using .NET at all and find a suitable replacement. Interfacing is almost my middle name. :veryhappy: I enjoy interfacing, and would interface everything to everything I can if this was possible.

What this will not prohibit, is a commercial company coming along and implementing some piece of that architecture however they wish. The only requirements would be that they adhere to the architecture in 1 (that is whatever pieces they wish to make perform the functions specified in the architecture), and that they communicate using the protocol defined in 2.
Anyone can come along and add a layer of .NET or whatever they want above what we do. What they can not do is change and redistribute those changes to our code without contributing those changes back to our project. We must benefit in some way from what others do with our code. They can do whatever they want on top of our code without making changes to our code. The same would hold true of somebody were making changes to our architecture and/or protocol(s) - changes must be contributed back to our project. I am not sure, but I believe the GPL covers this as well - I can never get though all the legal mumbo jumbo. :tongue: We can learn and get inspiration from what others do with our stuff even if they don't change anything, and it would be good to at least be advised of anyone using or building on our project.

This is a good thing. Take for example a visualization library. Because we few volunteers have limited time and resources, we might make it only use solid colors for instance. However, a commercial company could come along, dedicate a lot of time and resources, and their visualization library does UV mapping, ray tracing, phong shading, what have you. Both products (the open source and commercial) could be used in the same place, because they both adhere to the same standards.
Yes, indeed, I see this as being a good thing also and I see no reason why we could not work with such companies to create a better and more useful project/product. There is a lot of potential in creative alliances.

I believe Alex has already stated that he and Matt want to open source the whole .NET thing that they already wrote. It will of course have to be modified to adhere to whatever we decide the protocol is. But just because it is .NET does not mean that the rest of us have to use .NET ourselves.
I believe we have to replace .NET completely for this project to work out. We can't be using different environments if we are to create something cohesive, usable, and sensible. Let anyone who wants to, layer .NET above what we do and have our blessings to do so. :happy:

Because the protocol we define will be message passing of some sort, you will be free to write an algorithm library in C for instance, and it would communicate over a network to the .NET thing.
Firstly, let us get out of the whole .NET thing. :tongue: Let that be layered on top of our works by whomever wishes to do it, and I know there will be somebody. It could even end up being us, but let it be done later. We have much work to do before we even get to a point where .NET or other layers are even possible, but should definitely keep upper layer interfaces in mind as we progress.

8-Dale

[LinuxGuy]

Just because something is open source doesn't mean that someone can't make money from it.
This is certainly true. However, changes to our stuff, whether it be architecture/protocol and/or code, must be contributed back to us for possible inclusion in future releases. We can include what we feel will move our project forward and/or make it more useful. We should always foster a cordial working relationship with those wishing to use what we develop, regardless of what they are trying to do. We can all learn and be inspired by each other at any given moment.

8-Dale

[metaform3d]

Architecture:

Both CORBA and .NET are built on (although they both go well beyond) COM (http://en.wikipedia.org/wiki/Component_Object_Model). I would humbly propose using the most general form of COM as the basis of the TRS architecture. Its strengths are that it's platform and language-independent, object-oriented, and provides a unique form of runtime polymorphism. As a binary standard it's possible to create objects with many tools including .NET, Perl or Python, or hand-coded assembly if you so wish. There are also methods (albeit extensions of the basic model) that allow for using COM objects that reside on hardware over a network.

The drawbacks of COM are mostly apparent when dealing with a large distributed application, like web services. In particular COM objects are reference-counted, so they are not very robust to the types of errors that can occur in a distributed application. All robotic systems that I have seen tend to be tightly coupled and running on the same hardware so that should be less of a problem. The exception would be a mobile robot being controlled wirelessly by a remote brain, but the introduction of an explicit protocol should handle that case.

The modo SDK is based on this type of COM and I think it's fairly successful. I would be happy to contribute the code that we use to create COM objects in C++. Unlike ATL, this code is compiler-independent. I also have code for creating COM objects in straight C, although I would need permission to release it and it would require some rewriting to use standard libraries instead of our proprietary ones.

License:

Working in commercial software I can tell you that any license that will require a software vendor to make their own code public is the kiss of death. A license so aggressive that it makes anything it touches become open-source will consign it forever to the domain of hobbyists. A license that simply requires a company to make public any changes it makes to the source will also act as a disincentive for commercial software enterprises. They may use the system but their preference will be to work around problems in the code rather than to fix them. Even hardware companies that would like to be able to plug their components into your system will think twice before they commit to making their driver software public.

Would it be possible to use a two-tier system? The core of the TRS code could be used by companies but if they modified it they would have to make those modifications open-source. However specific objects that plug into the system could be licensed independently. This would allow hardware and software companies to decide which parts of their IP to release to the public, while still giving robot builders access to the functionality they need in an open architecture. This would be similar to Linux, where the OS itself is open-source but vendors can still sell proprietary applications and drivers.

[LinuxGuy]

Architecture:

Both CORBA and .NET are built on (although they both go well beyond) COM (http://en.wikipedia.org/wiki/Component_Object_Model). I would humbly propose using the most general form of COM as the basis of the TRS architecture. Its strengths are that it's platform and language-independent, object-oriented, and provides a unique form of runtime polymorphism. As a binary standard it's possible to create objects with many tools including .NET, Perl or Python, or hand-coded assembly if you so wish. There are also methods (albeit extensions of the basic model) that allow for using COM objects that reside on hardware over a network.
This sounds like it might be at least a good starting point. As long as we can use existing code that is not encumbered in anyway, that would be very good.

The drawbacks of COM are mostly apparent when dealing with a large distributed application, like web services. In particular COM objects are reference-counted, so they are not very robust to the types of errors that can occur in a distributed application. All robotic systems that I have seen tend to be tightly coupled and running on the same hardware so that should be less of a problem. The exception would be a mobile robot being controlled wirelessly by a remote brain, but the introduction of an explicit protocol should handle that case.
This is where we come in, of course. :happy: We can see where we need to make changes, and change the existing code if needed, or we can layer new code on top of the existing code, whichever method gets us to where we need to be.

The modo SDK is based on this type of COM and I think it's fairly successful. I would be happy to contribute the code that we use to create COM objects in C++. Unlike ATL, this code is compiler-independent. I also have code for creating COM objects in straight C, although I would need permission to release it and it would require some rewriting to use standard libraries instead of our proprietary ones.
We may potentially have our first commercial joiner here. Otherwise, I think we would welcome any code that can be released without any encumberance(s). I'm starting to look at various Open Source implementations of things like CORBA, SOAP (where is the WATER?), etc.

License:

Working in commercial software I can tell you that any license that will require a software vendor to make their own code public is the kiss of death. A license so aggressive that it makes anything it touches become open-source will consign it forever to the domain of hobbyists.
This is where I strongly disagree with the GPL. I think it is far too aggressive to the point of being unreasonable. I don't care what companies do to or with their code and libraries. I only care about what we are doing and what is done with stuff we develop - I just want any changes made to our code, architecture and protocol documents to be contributed back to us and that's all. If they don't change our code, I don't really care how they use it.

A license that simply requires a company to make public any changes it makes to the source will also act as a disincentive for commercial software enterprises. They may use the system but their preference will be to work around problems in the code rather than to fix them. Even hardware companies that would like to be able to plug their components into your system will think twice before they commit to making their driver software public.
A company might even contact us to request a change or submit an idea for a change or addition. We always have Matt and Alec to handle that sort liason between us and potential contributors (commercial or otherwise).

Would it be possible to use a two-tier system? The core of the TRS code could be used by companies but if they modified it they would have to make those modifications open-source. However specific objects that plug into the system could be licensed independently. This would allow hardware and software companies to decide which parts of their IP to release to the public, while still giving robot builders access to the functionality they need in an open architecture. This would be similar to Linux, where the OS itself is open-source but vendors can still sell proprietary applications and drivers.
Yes, indeed! I don't have any problem with this sort of thing. It's only our core and project I want to see protected, with the assurance we will get some sort of contribution (any changes to our code or documents would be mandatory as a minimum) in return if changes are made.

8-Dale

[Alex]

I was just talking to a really good friend of mine yesterday who's been a developer for over ten years now, Linux Guru, does mostly all open source work, etc. I talked to him briefly about the TRS and the topic here in regards to Licensing and how we were considering GPL license. Without knowing much about the TRS, it's goals and so on, he suggested a GNU license instead of GPL for many different reasons (most of which was totally over my head, haha). Again, for anyone that hasn't read in earlier posts, I am completely inexperienced in licensing, so don't kill the messenger;) I was just throwing this out there to see what everyone understood about GNU licensing and if it would fit here?

[Sienna]

First, let us be clear, I think there are two licenses involved here.
1) A 'license' regarding the Architecture and Protocol
2) A license regarding the code that we write as an example or initial implementation

The primary license I started this thread to talk about is 2 above, or the license we are going to do this initial stab with.

This is certainly true. However, changes to our stuff, whether it be architecture/protocol and/or code, must be contributed back to us for possible inclusion in future releases. We can include what we feel will move our project forward and/or make it more useful. We should always foster a cordial working relationship with those wishing to use what we develop, regardless of what they are trying to do. We can all learn and be inspired by each other at any given moment.

8-Dale

We are trying to propose an Industry Standard. As such, the Architecture and Protocol will at some point be out of 'our' control, and instead regulated by a standards body (hopefully). (There are other ways to do this, look at the MPEG LA for example. MPEG standards are licensed, in that that you have to pay to implement them. Another example are most IEEE standards (which are typically pay to get, not pay to implement). That just leaves a really bad taste in my mouth. I would personally rather see this as something like an RFC (which are free to get and implement).

The software license we are discussing will take care of changes to our code made by others. Also, please keep in mind that not even the GPL stipulates that changes must be flowed to the source project, only distributed with the code. A subtle distinction, but present nonetheless.

Both CORBA and .NET are built on (although they both go well beyond) COM (http://en.wikipedia.org/wiki/Component_Object_Model).
I disagree. From the exact wiki article you linked to:
Although the interface standard has been implemented on several platforms, COM is primarily used with Microsoft Windows (http://en.wikipedia.org/wiki/Microsoft_Windows). [...] COM is very similar to other component software (http://en.wikipedia.org/wiki/Component_software) interface standards, such as CORBA (http://en.wikipedia.org/wiki/CORBA) and Java Beans (http://en.wikipedia.org/wiki/Java_Beans), although each has its own strengths and weaknesses. It is likely that the characteristics of COM make it most suitable for the development and deployment of desktop applications, for which it was originally designed.
Very similar != built on. The other major factor I could not find on COM is where are the standards? This is also a problem when talking about "Web Services", in that there is no interoperable standards yet.

Would it be possible to use a two-tier system? The core of the TRS code could be used by companies but if they modified it they would have to make those modifications open-source. However specific objects that plug into the system could be licensed independently. This would allow hardware and software companies to decide which parts of their IP to release to the public, while still giving robot builders access to the functionality they need in an open architecture. This would be similar to Linux, where the OS itself is open-source but vendors can still sell proprietary applications and drivers.

I believe this is the goal behind distributing the protocol and architecture separately from the code we will develop. Because the protocol is publish and 'network*' centric, you should be able to remove a GPLed module and put in a commercial module for instance.

*lets not get into the dissemination architecture just yet :P

I was just talking to a really good friend of mine yesterday who's been a developer for over ten years now, Linux Guru, does mostly all open source work, etc. I talked to him briefly about the TRS and the topic here in regards to Licensing and how we were considering GPL license. Without knowing much about the TRS, it's goals and so on, he suggested a GNU license instead of GPL for many different reasons (most of which was totally over my head, haha). Again, for anyone that hasn't read in earlier posts, I am completely inexperienced in licensing, so don't kill the messenger;) I was just throwing this out there to see what everyone understood about GNU licensing and if it would fit here?

From what I understood, GPL = GNU General Public License. Again, we have two "licenses" to discuss, the one for the architecture and protocol, and the one for the code we will work on. The architecture/protocol license needs to be fairly permissive in order for it to become an industry standard. The code license can be as restrictive as we wish, as it only makes up modules in the system that others are free to replace. If you wish, I suppose we can consider something like the LGPL, which would allow others to link our code commercially, but I am not sure the benefit there. There are also more permissive licenses like the BSD license, but I am not so much familiar with them.

[Matt]

Man, people you are going to send me to an early grave! :p Actually, this is a great discussion. We are going to lock the few TRS related threads for a few minutes to do some organizing. (Starting up a new forum to house it all.) So bear with us for a moment while we kick up a little construction dust.

[Matt]

Okay, I'm back and I didn't gamble away the company, but the natives have gone wild in my absence, LOL.

First let me readdress the licensing / open source issue for everyone. Sienna pretty much nailed it in post #22, but I'll reiterate in my own words.

We began this project with three main goals in mind:

1) The main components of the TRS (TROM, TRAL, Sensor & controller library, rendering tool) are not intended for sale. These were/are to be given away for free to the robotics community to establish a new standard. The goal being that once the standard has begun to propagate it gets moved on over to an official standards body with a committee. We are trying to seed a standard and have at the same time identified what we think the most logical architecture should be in terms of modular software components.

2) The architecture is also consciously designed so that normal capitalism can thrive around the standard and people can build profitable products and companies around the core tools and standards. We WANT a robotics ecosystem to grow around what we are building here.

3) No Box - no dependency upon certain languages, hardware, Operating systems, or software.

There are really only two main "core" components if we think about it that require the most long term protection 1) the TROM and 2) the Sensor & Controller Library. The other two components, the algorithm library and rendering tool, we need to build ourselves because they don't exist yet. However, I anticipate (hope even) that other companies show up to build amazing rendering tools and algorithm libraries that they sell. I also hope that the community always has a free version of each out there for anyone to get started with.

I think that inside the "which license" discussing people are asking for us (TR) to state our position/commitment officially so I will:

Q: If we work on this are you promising you won't turn around and allow it to get tied up into a proprietary system?
A: Yes, we can promise we won't do anything of the sort. We are committed to this being an open source project with the appropriate licenses being applied. I can't promise that people won't make money because they will and that's okay. However, the work done here is intended to make it's way into a standards body and to move the industry forward as a whole. We won't make any decisions contrary to that goal.

I think we are all circling around the correct licensing answer right now. We want a license that protects the core from being kidnapped by any one company while encouraging innovation and entrepreneurial adoption of the standards. As Jodie said when we chatted, this is probably best done copying the Linux model.

Half of this thread has turned into a discussion of protocols, architecture, and languages. We should start a new thread for those topics and pull the discussion back to just the licensing issues in here. (I'll break out the other threads this evening and carry over the items being discussed.)

Thanks Everyone! We are unwittingly birthing skynet at this very moment, how exciting!

[HumanoidFan]

Hi,

I have been following this thread and have also had lots of conversations and discussions about licensing.

The license that is picked should be as open as possible, allowing commercial and non commercial entities to access and use the code.

OpenCV uses the BSD licenses, this licenses allows maximum flex, but also means the code can be taken and used for any purpose.

The Eclipse or WXWidgets licenses are really good, they allow linking to the code and embedding the code, but all modifications have to go back to the project.

What ever license is picked, it should allow anyone to link to any part of the TRS without fear of making their own modules or higher level code open.

[Matt]

What ever license is picked, it should allow anyone to link to any part of the TRS without fear of making their own modules or higher level code open.


Agreed, as another poster said earlier, an overly aggressive GPL is the kiss of death for real market adoption. We are going to steer very clear of that. I don't think anyone here wants to work on a vanity project that doesn't proliferate.