Linked by Thom Holwerda on Mon 13th Nov 2006 22:21 UTC
Zeta One of the things that has been missing on the BeOS platform, either for BeOS, ZETA or Haiku, is pthread, and this was also something that yellowTAB experienced when they were working on a port of OpenOffice. Hence, the development team has released support for phthread. This improvement will be contributed to Haiku as soon as it reaches a more mature state.
Thread beginning with comment 182180
To read all comments associated with this story, please click here.
yellowTAB's licensing...
by looncraz on Tue 14th Nov 2006 16:50 UTC
looncraz
Member since:
2005-07-24

Okay... I obviously have to kick in here...

Prior to Be's death, yellowTAB had an agreement with Be, INC for rights to distribute a customized BeOS Personal Edition.

When yellowTAB was moving to the Dano base, it was ( at least originally ) a binary tree with source on top for building the system. This was needed as there was NO source code for the system itself.

What now is not known, is only what I was unable to figure out prior to my exit from yellowTAB... does yellowTAB have source? Do they have a legal right to that source?

The only thing, however, I do know is that yellowTAB was, in fact, given permission, in a manner, by the response from the owner of Be's IP: We don't give a rats arse about this crap, not our line of business. It was purchased to add value to the company, no other reason but to make our stockholders happy.

BTW, upon releasing each of my seven Dano-based distributions, I worked primarily with that knowledge. The product is not technically legal, but I have confirmation of moratorium.

I had to get a lawyer to find out if I was safe with what I could prove. I was assured as such after acquiring more information in quest of making a legal Zeta only.

The thing is, however, that there are many things that had to be taken into consideration within the system itself: third-party licenses acquired by Be, INC. In order to make the Dano base system legal, certain components needed one of two things: removal or a license.

Of course, with removal... comes replacement. This is why PhOS Beta 4, 5, & 6 are so radically departed from each other in accompanying applications. I had to ENSURE that the system was technically only released to Beta testers ( just public Beta testing :-) ), and that any sells were obviously not meant to make money, just to essentially cover costs incurred for the Beta process.

The law applies to OFFICIAL releases of software. The purpose is to allow protection for research projects at large corporations. It means the business has to go as far as to actually publish, en mass, to the public for sale / distribution. The Beta process, within the software world, is a essentially a part of R&D as seen by the law in regards to this matter.

Please note, though, I am NOT a lawyer, and it has been a while since I have exited the beta phase within the development life cycle for my product. Which, of course, means I can no longer skirt the legal boundary as I was. I would now prosecutable under law if I were to release a non-Beta version. BUT, I went from alpha to beta in six months, and it took 3 years from beta to internal only ( no public advertisements for derived or potentially infringing products allowed during this time (unless your asking for trouble) ).


Of course, yellowTAB fell out of this model rather a while back. Then suddenly got itself a, most likely, legal-guard (blinder): Magnussoft.

Naturally, I can only throw conjecture forth towards the legal status of Zeta based on what I know from a few years ago. Times change quickly, and yellowTAB has clearly demonstrated that they at least have the ability to modify the kernel code. So the only question to be answered?

Do they have a right to re-sell their products?

That is important, because if they do not, any of the third-party license holders could also sue yellowTAB / magnussoft and perhaps even their partners for back-royalties on their product inclusions, at the rate Be, INC charged + a min of $750 per unit fine.

BTW, that $750 would be required ( amount will depend on the nation of complaint's legal proceedings as hedged with various international laws regarding copyright and intellectual property rights as pertaining to international and "virtual" businesses ).

If yellowTAB had any legal rights, I think they would WANT to make those public in this case, though just to the effect of saying: "Yes, we have the legal right to produce our product and distribute it."

If a company says that, you have no fear from working with them. Even if it turns out not to be true, you may refer to that statement and not be harmed. Without such a statement, it is possible that lawsuits could, technically, be waged. However, if you recall the aforementioned response from the owners in regards to the intellectual property in question... they don't care.. that is all yT is going on until I hear otherwise.

For the average consumer, it will only mean yT could eventually not be around, but that is most likely anyway. Buying Zeta will not endanger you in any way. But partnering or entering into certain contracts with yellowTAB would be very, very, iffy.

SO, Magnussoft exists to provide a company that is licensing from yellowTAB, so that, in the event of yellowTAB being sued, Magnussoft could still continue, meaning yT exists on paper now, Magnussoft is what happened to the physical aspects of it.

See? Now, of course, Magnussoft would have no reason to exist if yellowTAB had legal rights.

--The loon

PS: I had the legal right to draw into question the legality of the project I was working on at yellowTAB, and did so regularly. The only answer I ever got was, "we are trying, it would be cool."

_____________________

EDIT: Clarification, inadvertently made it seem like I was releasing Zeta Beta 4, 5 & 6. And fixed a fully reversed sentence ( dyslexic ).

Edited 2006-11-14 17:08

Reply Score: 2

RE: yellowTAB's licensing...
by Ronald Vos on Tue 14th Nov 2006 17:31 in reply to "yellowTAB's licensing..."
Ronald Vos Member since:
2005-07-06

Going by the information you're providing, yT/MS are safe as long as JLGs heading Palm, but if Zeta becomes very succesful and when Palm goes down the crapper and gets bought up by Microsoft, they're in big trouble. ;)

Reply Parent Score: 1

RE[2]: yellowTAB's licensing...
by MYOB on Tue 14th Nov 2006 17:36 in reply to "RE: yellowTAB's licensing..."
MYOB Member since:
2005-06-29

PalmSOURCE (note, not Palm, the hardware company) got bought out nearly a year ago and is going to cease to exist as a brand, etc, shortly. ACCESS now own BeOS, not Palm.

Reply Parent Score: 2

RE: yellowTAB's licensing...
by stew on Tue 14th Nov 2006 18:00 in reply to "yellowTAB's licensing..."
stew Member since:
2005-07-06

Now, of course, Magnussoft would have no reason to exist if yellowTAB had legal rights.

Magnussoft existed long before the yT/Zeta deal. They have been distributing games in Germany for years.

Reply Parent Score: 2

RE[2]: yellowTAB's licensing...
by stew on Tue 14th Nov 2006 20:59 in reply to "RE: yellowTAB's licensing..."
stew Member since:
2005-07-06

To be more precise, archive.org's wayback machine lists magnussoft.de since 2001, whereas yellowtab.de starts in 2002.

Reply Parent Score: 1

RE: yellowTAB's licensing...
by StephenBeDoper on Wed 15th Nov 2006 10:53 in reply to "yellowTAB's licensing..."
StephenBeDoper Member since:
2005-07-06

So... how's it going with that Flash player you were writing? ;)

Reply Parent Score: 3

RE[2]: yellowTAB's licensing...
by looncraz on Thu 16th Nov 2006 18:42 in reply to "RE: yellowTAB's licensing..."
looncraz Member since:
2005-07-24

Flash Player...

I had originally intended of making a GPL flash player work on BeOS. Which I did. Only problem is that the claims of functionality from the code were somewhat misrepresented.

That is not a show stopper, but it has put the work onto the back boiler as I struggle to keep my head above waters in the real world.

However, I have a fully planned development cycle involving other projects, mine AND those of others', that will comprise components of a complete new flash-similar live content system. At first the generation will occur through a form of XML, with behavioral methods via in-line scripting.

This will be the raw language for handling many different types of interactive streaming data within the Serenity framework. I am hoping, soon, to come up with some time away from developing, to get the project better organized in the public world. The major hold-up in this arena was my dependence on BeOS Dano R5.1d0, and my investigations into best-possible integration with Haiku above ALL-ELSE.

This likely means I will be donating to Haiku soon, because FINALLY our interests have overlapped in several highly critical areas that my involvement would in no possible way cause any questions, because my long-gone PhOS and SuprDANO distributions.

The technologies in question are, naturally, XML parsing, SVG handling ( and related code ), SVG Rendering, and such other technologies that were, at no time, heavily ( or ever ) utilized by Be, INC for BeOS ( even unreleased builds ).

This is the order of events for the Haiku-compatible Flash Player, which will likely run on R5 with some libhaikuOS-compat.so for R5 :-) Also, much is already in some state of operation:

-> Build synchronized, Haiku-only build environment
....60% or so, still trying to iron out some paths.

-> Core Facilities
1. Thread=*, *Manager, *Group, Smart*Group
...a Service=*, *Manager
...... Core facilities are components from my LoonTracker project, and are mostly complete.

2. XML Parser
... where Haiku or other code will likely be used
... to speed up development.

3. SVG abstraction ( C++ ideally )
... This WILL be utilized from libicon.a from Haiku
... as well as #
4. SVG Render ( ^^^ )

From there there is still the in-line scripting and the scripting language.

I have decided that I will need to do a lot of experimenting on the best way to create a set stream of actions to be performed entirely within the contexts necessary to provide compatibility with multiple paradigms for this type of functionality.

Meaning, the interaction framework, so the player can support FULL scripting. From then it is nothing but polishing and testing of our raw format directly, then some more simplistic file format translators before finally assembling everything needed to translate the raw stream data ( which would have been created by an up-front read-formatter ( so the data comes in as a set of streams among various threads and by multiple concurrent services, piggy-backing on a near real-time ( just constant time with async move instead of copy ) messaging system ( 99% complete ))).

All that means, is that the pieces of the system are there, they really just need individual polish, then assembly, then testing, further polishing, then expansion to handle formats other than an internal format. The idea is to achieve 100% CAPABILITY to support flash and whatever other similar formats their are.

I may get around to writing a flash module set, but may not. If so, you can rest assured that I will be looking for a MUCH better source of flash handling than what I found originally. Problem is, I am picky.. sometimes maybe too picky :-)

--The loon

Reply Parent Score: 1