Porting Various Operating Systems To Pandora?

[tmcnair]

QUOTE

And they got it back, as was intended all along. The actual issue was that GPH themselves didn't write the firmware. The contracted an outside company to do it, and that company screwed up. They included non-GPLable code in with the linux-based firmware. When GPH received the firmware with the source they realized they couldn't release it, but they had already taken pre-orders and people were clamoring for the hardware. They had a choice of delaying shipment for another couple months while the firmware was sorted out or shipping what they had and fixing it later.

They did the right thing and shipped what they had. They then removed the offending bits of code and sent out the new firmware and all relevant source code a couple months later.



Yes, and the irony of all that is they were scrambling to not violate their proprietary licenses in order to somewhat meet the terms of the GPL. Why is it OK to piss all over one licensor to protect another? Because GPH knew all that really would happen is people would bitch and moan about the GPL while if they distributed proprietary code they'd have their lunch handed to them in court. Meanwhile the attitude "we aren't making any big bucks off it so whats the big whoop?" prevails. Licenses are licenses - just because you don't have to pay any $$ for GPL code doesn't mean it is yours to do with as you please - it has a cost.

 

[Megamixman]

What IPs do they really have to protect in comparison to nVIDIA / ATI / Intel / VIA? I don't see binary-only being practical, especially so regarding driver development -or- IP protection at this point.

The Desktop market has nothing on IPs in comparison to the embedded market. For Desktop Graphics, optimizing the pipe and then 'effectively' copying and pasting it over and over is the main way in which GPUs evolve.

Embedded graphics have to be far more ingenious, and the drivers have to reflect this. There are different ways in which pipes operate, possibly bus configuration, who knows what. But the fact is that a lot more effort has to be done to make a low power GPU then it is to make a powerfull GPU.

There is also the fact that Embedded IP is a much hotter market. The Qualcomm fiasco is a good example of how serious Embedded IP is, both in terms of protecting your own rights, and going after other's IP. Think of the number of computers sold. Now think of the number of cellphones, PDAs, GPS, MP3 Player, <Insert Gadget here>, etc. It also a market that is still rapidly growing, with manufacturers finding things like SMART appliances, homes, cars, etc. as sub-saturated markets that are ripe for money making. Finally, a LOT of embedded companies rely on the abililty to sell their IP rather then the silicon itself. So companies like ImgTec will do everything they can to protect their main assets, their IP.

 

[Chip]

Yes, and the irony of all that is they were scrambling to not violate their proprietary licenses in order to somewhat meet the terms of the GPL. Why is it OK to piss all over one licensor to protect another? Because GPH knew all that really would happen is people would bitch and moan about the GPL while if they distributed proprietary code they'd have their lunch handed to them in court. Meanwhile the attitude "we aren't making any big bucks off it so whats the big whoop?" prevails. Licenses are licenses - just because you don't have to pay any $$ for GPL code doesn't mean it is yours to do with as you please - it has a cost.

If you err on the side of delaying the release of source code, you can always make it right by releasing it later when it is clean. If you err on the side of releasing proprietary code which you do not own, you cannot take it back. If you err on the side of not releasing anything, you run the risk of alienating your users and bankrupting your company with canceled pre-orders. Like I said, GPH made the most of a tough situation and in the end no harm was done. Your attitude of "That's not good enough" is exactly that with which I have a problem. The GPL may have been written with nothing but good intentions, but in this particular situation, the letter of the law was too strict. The people who demanded the license be followed to the letter and would accept nothing less were out of line.

 

[tmcnair]

QUOTE

If you err on the side of delaying the release of source code, you can always make it right by releasing it later when it is clean.
If you err on the side of releasing proprietary code which you do not own, you cannot take it back. If you err on the side of not releasing anything, you run the risk of alienating your users and bankrupting your company with canceled pre-orders.



Or you can not err at all and simply wait to release the source along with the binary. So GPH was caught in a catch 22 with their first release - lets give them the benefit of the doubt that they didn't understand the license. They get to use that excuse exactly once. What is the excuse now? 4.0.2, 4.1.x is out but still only source for 4.0.0. This is annoying because I'm fiddling with the kernel and I'd like the benefit of their bug fixes. This is the quid pro quo that makes open source work. The community benefits with timely releases of source.

QUOTE

Like I said, GPH made the most of a tough situation and in the end no harm was done. Your attitude of "That's not good enough" is exactly that with which I have a problem. The GPL may have been written with nothing but good intentions, but in this particular situation, the letter of the law was too strict. The people who demanded the license be followed to the letter and would accept nothing less were out of line.



Can you explain how it is too strict? All it asks is that release of sources accompanies the release of a binary, and that access of source is granted to anyone. What is so strict about that? The only price GPH has paid for not honoring the license is that some people got annoyed in an online forum. That seems like a pretty sweet deal to me. And yeah - it is not good enough - they need to meet the terms of the license, not the parts that they (or you) deem acceptable. Like it or not GPL is not public domain and it is not charity.

To take your argument to its logical conclusion -" I feel like asking me to pay $4.00 a gallon for gas is an outrage - I'll just pay $3.00". I guess if all that happened was some dude at the filling station got a little pissed I might be tempted...

 

[tmcnair]

Bringing this home with something relevant to Pandora: in the bigger picture this isn't about following the letter of a license, it is about understanding the GPL and making it work for them. If the Pandora crew are using linux just because it is inexpensive then they simply aren't getting the value out of it that they could. The GPL hasn't lasted as long as it has and become as successful as it is because it sucks - it is actually a /really/ well thought out scheme for ensuring all players involved get the benefits of collaborative development. Releasing source in a timely manner means more eyes see it and can fix and enhance it. The nature of the license means that pandora are likely to get those improvements back.

Pandora, if they end up using linux, are not responsible to release the source until they've made a public release of the OS - but why even wait that long? It would only benefit themselves to open up their repository prior for all to see. If they really want a vibrant developer communtiy, which is a benefit to everyone involved, then they need to:

1) Embrace the GPL to get the most value out of the OS they've chosen.

2) Open up their code repository with read access to everyone and accept patches from the community. Do this as early as possible - people like myself will follow along and will be more up to speed when we have a chance to get a unit.

3) Provide a well-documented and stable toochain. Own it and support it just as they would own and support their released firmware.

4) Where possible, choose hardware from manufacturers that are friendly to open source or where open source drivers are already available. Again, this is about getting the most value out of the open source OS which they've chosen to use. I realize this is not always practical (e.g. PowerVR), and some decisions have already been made - but I'd gladly pay a bit more or accept lower performance for a part that has open source drivers.

5) Be open about project progress - even if it means some egg on the face when deadlines aren't met or can't realistically be met.

GPH completely blew it for themselves and the community with respect to 1, 2, 3, and 5. I haven't seen a Pandora yet but it sounds like they are already going to be worse than GPH with respect to #4 - I hope they do better on the others.

 

[Megamixman]

1.) They are doing this auto-magically by using a linux based OS. Craigx said they are working with the beagelboard team on this.

2.) Main problem here is that no one has a good way of testing things besides the devs. Untested code is not safe code. Unsafe code is bad for a PRODUCT. Remember Pandora is a product as much as it is a community project.

3.) They don't really need to do much here so it's likely going to happen.

4.) The problem here is that you're once again dealing with the embedded realm. Things are not as easy or interchangeable as in the PC realm. You can't just take out one chip and replace with another most of the time. There are generally design consuquences that affect the whole system and board design.

5.) NDA. End of story.


Your gripe with the hardware is the biggest indicator that you don't have a clue as to the hardware challenges in the embedded realm. The USB PHY alone is a good example. TI used their own bus schemes and thus they were highly limited in what USB PHYs they could use. This extends to every part. On top of this with parts such as the wifi chip you can easily have problems where changing the part means redesigning the board due to RF Characteristics.

The only companies with the capability of satisfying all your requests as major players in the Consumer Electronics area like Samsung and Nokia, who have the money to build Custom SoCs along with directly licensing the IPs needed. These are the companies least likely to grant everything your asking for because they can appeal to the far greater Consumer market with a solid device that does what it does well and not much more.

I'm not saying, screw the GPL, but you have to consider that the GPL, while it may be a good license for the x86 computer market, tends to be much more of a restrictive license in the embedded market, where other factors have far greater influence. (Run on Sentence Alert Activated)

 

[MWeston]

1) Embrace the GPL to get the most value out of the OS they've chosen.

2) Open up their code repository with read access to everyone and accept patches from the community. Do this as early as possible - people like myself will follow along and will be more up to speed when we have a chance to get a unit.

3) Provide a well-documented and stable toochain. Own it and support it just as they would own and support their released firmware.

4) Where possible, choose hardware from manufacturers that are friendly to open source or where open source drivers are already available. Again, this is about getting the most value out of the open source OS which they've chosen to use. I realize this is not always practical (e.g. PowerVR), and some decisions have already been made - but I'd gladly pay a bit more or accept lower performance for a part that has open source drivers.

5) Be open about project progress - even if it means some egg on the face when deadlines aren't met or can't realistically be met.

1) Yeah, I agree with you. We don't want any GPL violations and if something happens with third party drivers that we aren't aware of, we will be right on the battlefront with everyone else demanding resolution from the code provider. These companies we are working with are well spoken and experienced with Linux drivers and maybe they have never had a customer with such an open product, but I sure hope they have gotten it right.
2) I think this will be done soon. Some developers want to do that as soon as they feel it doesn't look like a twisted mess or maybe when it actually runs well or just maybe when they have the time to set up a repository. I don't know where that is right now.
3) Well, whatever we use is what everyone else can use so that doesn't sound like any trouble. Some key Beagleboard devs have been analyzing different compilers to see which ones perform terribly under certain situations and which is the best one to use for different applications (ie. NEON, A8 stuff)
4) Well, there was a time when the 3D driver was going to be the ONLY closed source. We had a nice Atheros 6001 based chipset designed in and then our sales liaison guy in China ran off with the money and we never could get back on track with that module. The communication with this new company is fantastic and they are well tied into TI so we can count on their reputation. It isn't likely that a whole bunch of people will be able to really work with the source code anyway and if there is someone out there that can really add to the code, we could look into get them under the NDA to work on it. It's a decent solution to an unavoidable problem I think.
5) Well, that busted board fiasco cost us TWO MONTHS worth of time getting a whole bunch of boards out to kernel developers and that still weighs heavily on my mind as we enter July. We shared that one and that was a major whoops. We shared the Analog nub problem and a bit about the wifi problem.

 

[tmcnair]

1.) They are doing this auto-magically by using a linux based OS. Craigx said they are working with the beagelboard team on this.

They're using Linux, it remains to be seen if they will embrace the license that Linux is under and make the most of it. If they go the way of GPH and do development behind close doors only to surface with a release now and then they are doing themselves and the community a disservice. My point is - they are required to release the source anyway - why not make the most of the situation and release early and often - what is the downside?

QUOTE

2.) Main problem here is that no one has a good way of testing things besides the devs. Untested code is not safe code. Unsafe code is bad for a PRODUCT. Remember Pandora is a product as much as it is a community project.



Huh? Opening up the repository doesn't prevent them from tagging stable releases. How on earth could you be against making the current version of the code available to other developers? DJWillis seems to agree (from beagle IRC logs):

[21:33:04] <DJWillis> sakoman: is GIT easy to setup? Never tried it, tempted to move my kernel hacking from our project SVN to a public GIT.

Please do DJWillis!

QUOTE

3.) They don't really need to do much here so it's likely going to happen.



Yeah - if they use OE they are in great shape in this department.

QUOTE

4.) The problem here is that you're once again dealing with the embedded realm. Things are not as easy or interchangeable as in the PC realm. You can't just take out one chip and replace with another most of the time. There are generally design consuquences that affect the whole system and board design.



I'll give you that - I do not know what difficulties are involved in this. My position is that all other things being equal - I'd rather see hardware used that is open-source friendly with respect to drivers. I would have to think that is also the position of the Pandora devs. From your description it sounds like they are making the best of what they have access to on a limited budget.

QUOTE

5.) NDA. End of story.



NDA does not prevent them from giving project stats updates and being realistic with dates. They already missed june/july. If someone is not holding a complete prototype in their hands by now with at least a semi-functional firmware I wonder how they can possibly make August. I'll be happy to be proven wrong.

QUOTE

Your gripe with the hardware is the biggest indicator that you don't have a clue as to the hardware challenges in the embedded realm. The USB PHY alone is a good example. TI used their own bus schemes and thus they were highly limited in what USB PHYs they could use. This extends to every part. On top of this with parts such as the wifi chip you can easily have problems where changing the part means redesigning the board due to RF Characteristics.

The only companies with the capability of satisfying all your requests as major players in the Consumer Electronics area like Samsung and Nokia, who have the money to build Custom SoCs along with directly licensing the IPs needed. These are the companies least likely to grant everything your asking for because they can appeal to the far greater Consumer market with a solid device that does what it does well and not much more.



My "requirement" on hardware was to prefer open-source friendly hardware where practical. So "where practical" is different for a small project vs a big company - the requirement can still be met. All the other "requirements" are dead easy.

QUOTE

I'm not saying, screw the GPL, but you have to consider that the GPL, while it may be a good license for the x86 computer market, tends to be much more of a restrictive license in the embedded market, where other factors have far greater influence. (Run on Sentence Alert Activated)



I'm not saying love the GPL. I'm saying recognize what it is and use it to your advantage.

 

[tmcnair]

1) Embrace the GPL to get the most value out of the OS they've chosen.

2) Open up their code repository with read access to everyone and accept patches from the community. Do this as early as possible - people like myself will follow along and will be more up to speed when we have a chance to get a unit.

3) Provide a well-documented and stable toochain. Own it and support it just as they would own and support their released firmware.

4) Where possible, choose hardware from manufacturers that are friendly to open source or where open source drivers are already available. Again, this is about getting the most value out of the open source OS which they've chosen to use. I realize this is not always practical (e.g. PowerVR), and some decisions have already been made - but I'd gladly pay a bit more or accept lower performance for a part that has open source drivers.

5) Be open about project progress - even if it means some egg on the face when deadlines aren't met or can't realistically be met.

1) Yeah, I agree with you. We don't want any GPL violations and if something happens with third party drivers that we aren't aware of, we will be right on the battlefront with everyone else demanding resolution from the code provider. These companies we are working with are well spoken and experienced with Linux drivers and maybe they have never had a customer with such an open product, but I sure hope they have gotten it right.
2) I think this will be done soon. Some developers want to do that as soon as they feel it doesn't look like a twisted mess or maybe when it actually runs well or just maybe when they have the time to set up a repository. I don't know where that is right now.
3) Well, whatever we use is what everyone else can use so that doesn't sound like any trouble. Some key Beagleboard devs have been analyzing different compilers to see which ones perform terribly under certain situations and which is the best one to use for different applications (ie. NEON, A8 stuff)
4) Well, there was a time when the 3D driver was going to be the ONLY closed source. We had a nice Atheros 6001 based chipset designed in and then our sales liaison guy in China ran off with the money and we never could get back on track with that module. The communication with this new company is fantastic and they are well tied into TI so we can count on their reputation. It isn't likely that a whole bunch of people will be able to really work with the source code anyway and if there is someone out there that can really add to the code, we could look into get them under the NDA to work on it. It's a decent solution to an unavoidable problem I think.
5) Well, that busted board fiasco cost us TWO MONTHS worth of time getting a whole bunch of boards out to kernel developers and that still weighs heavily on my mind as we enter July. We shared that one and that was a major whoops. We shared the Analog nub problem and a bit about the wifi problem.


Wow thanks for all that! It is wonderful to hear your comments, which shed light on many things I've been wondering about this project.

I do apologize for my skepticism on the estimated release dates but one thing I know from projects that I am involved with - the unexpected will happen, and with the nature of this project it seems as though you will have more to come. As I said in another post I'll be happy to be proven wrong but I'm not holding my breath for August. Happy hacking...

 

[Squidge]

They're using Linux, it remains to be seen if they will embrace the license that Linux is under and make the most of it. If they go the way of GPH and do development behind close doors only to surface with a release now and then they are doing themselves and the community a disservice. My point is - they are required to release the source anyway - why not make the most of the situation and release early and often - what is the downside?

Once the source code is in a suitable state, it will be released (most likely before the Pandora goes on sale). Further development will be done openly.

The point is that the current kernel code may contain information that is under NDA (for various development reasons, testing of hardware using code supplied by third parties, etc), and so is only available for the current kernel developers. Since the current kernel has not been released to the public, it is legal to keep the source under wraps. Once all the hardware drivers are finished, there will be no reason to "go behind closed doors" again.

 

[Megamixman]

Huh? Opening up the repository doesn't prevent them from tagging stable releases. How on earth could you be against making the current version of the code available to other developers? DJWillis seems to agree (from beagle IRC logs):

[21:33:04] <DJWillis> sakoman: is GIT easy to setup? Never tried it, tempted to move my kernel hacking from our project SVN to a public GIT.

Please do DJWillis!

Fine and dandy, but as of right now the only people who can test code that is Pandora specific, are people with the MK0 boards. Until Pandora is released, I don't see this as the best possible idea. You want people to test their code before it is posted to svn/git/mercurial/cvs/git/etc. Same goes before they provide patches.

NDA does not prevent them from giving project stats updates and being realistic with dates. They already missed june/july. If someone is not holding a complete prototype in their hands by now with at least a semi-functional firmware I wonder how they can possibly make August. I'll be happy to be proven wrong.

Which they have been doing to the limit that NDAs allow them. NDAs generally prevent specifics from being released. They can generalize the problem like they did with the boards being bent or the USB chips, but specifics such as dates on getting new boards or chip revisions are things that most companies, when they use NDAs, want to be kept secret until everything is official. I don't know what exactly is covered under their NDAs, but they have provided more then enough info to be able to put 2 and 2 together with information from TIs site and the beagleboard site.