Slashdot is supposed to be News for Nerds, not Propaganda for Nerds. There are three sides to this story: SCO's side, the anti-SCO side, and the truth. Only one side is appearing anywhere on slashdot, and it isn't the truth.
IANAL, but I do wonder if this propoganda is actually incredibly relevant to the case. It seems like the core issues aren't really copyright law or IP law, but rather based in contract law. The various sides are essentially arguing different interpretations of contract language, both of the sale of Unix to Caldera and of the initial license contracts between AT&T and other Unix developers. So...assuming a judge/jury would find the language unclear...what would a judge/jury use to choose one meaning over the other?
I'd have to think that this propoganda that purports to show the 'original intention' of the language would be used as evidence to back up one side's specific interpretation of the text. It'd probably be even more persuasive to a jury of people who don't possess contract grammar parsers. If it's already being used so dramatically in the court of public opinion, what's to prevent it from being used in court itself?
Mr. Ryan E. Tibbitts
General Counsel
The SCO Group
355 South 520 West
Lindon, UT 84042
Re: Sequent Computer Systems
Dear Mr. Tibbitts:
On May 29, 2003, SCO sent a letter to Sequent Computer Systems providing notice that it would terminate Sequent's SVRX license agreement as of September 2, 2003 if Sequent did not remedy certain alleged breaches of the license agreement. On August 11, 2003, SCO sent another letter to Sequent purporting to terminate Sequent's SVRX license agreement. IBM, on behalf of Sequent, responded to these letters by letter of August 14, 2003.
As it has with IBM and other SVRX licensees, SCO appears to be taking the position that code developed by Sequent, or licensed by Sequent form a third party, which Sequent incorporated in its UNIX variant but which itself does not contain proprietary UNIX code supplied by AT&T under the license agreement betwee AT&T and Sequent (Sequent Code), must nevertheless be maintained as confidental and may not be contributed to Linux. As we have said before, SCO's position defies both logic and the terms of the SVRX license agreement.
SCO cites, as support for its position, section 2.01 of Sequent agreement, which, like other SVRX licenses, provides as follows:
Such right to use includes the right to modify such SOFTWARE PRODUCT and to prepare derivative works based on such SOFTWARE PRODUCT, provided the resulting materials are treated hereunder as part of the original SOFTWARE PRODUCT.
As we have said, however, this provision merely confirms that AT&T retained ownership of its code even if it was incorporated in a derivative work, and does not purport to impose confidentiality or use restrictions on Sequent Code.
In fact, SCO's interpretation of 2.01 is plainly contrary to the position taken by AT&T, as author of and party to the SVRX licenses. AT&T clarified the meaning of section 2.01 in its $ echo publication, which AT&T described as its own newsletter to reach all UNIX System V licensees through one defined medium and keeps them abreast of any product announcements, policy changes, company business and pricing structures.
Specifically, in an edition of $ echo dated April 1985 (the same month that the Sequent license agreement was signed), AT&T announced that changes would be made to hte SVRX license agreement to clarify ownership of modifications or derivative works prepared by a licensee. AT&T said this and other announced changes were in response to direct feedback from AT&T licensees and [were] intended to make the contracts more responsive to the needs of licensees. AT&T then followed up by adding to section 2.01 a sentence clarifying that AT&T claims no ownership interest in any portion of such a modification or derivative work that is not part of a SOFTWARE PRODUCT. Even more clearly, the August 1985 edition of $ echo explained that this sentence was added to assure licensees that AT&T will claim no ownership in the software that they developed - only the portion of the software developed by AT&T. Copies of the April and August 1985 editions of $ echo are enclosed for your convenience.
For these reasons, and the reasons stated in our October 7, 2003 letter to you about IBM-developed code, SCO's position on Sequent Code is unsupportable.
Under Section 4.16(b) of the Asset Purchase Agreement, Novell retains the right at Novell's sole discretion and direction, to require SCO to amend, supplement, modify, or waive any rights under, or...assign any rights to, any SVRX License to the extent so directed in any manner or respect by [Novell]. That section further provides that to the extent SCO shall fail to take any such action concerning the SVRX Licenses as directed by Novell, Novell shall be authorized, and hereby is granted, the rights to take any action on [SCO's] own behalf.
Accordingly, pursuant to Section 4.16(b) of the Asset Purchas
and the Aqua widget set (usable from Objective-C, Java and C++ at least
While the Aqua widget set is accessible from a number of languages in the sense that the buttons look the same, the interfaces across the different languages definitely do not have the same level of parity. An example from Panther is metal buttons which are only accessible from Cocoa/Objective-C. Earlier versions of OS X even had more major interface elements unavailable to Carbon, such as sheets and drawers.
The underlying widget set of OS X has access from a very wide set of languages, but it's not yet fully language neutral in the sense that new widgets are automatically available in every language. Even though it's been getting better, the choice of APIs still places limits on which subset of the Aqua user interface elements can be used.
I never really knew about how a polygraph worked until I went to work for a company that does physiology equipment and software for research and education. On our website is a video of polygraph data (caution, 5 MB, windows media 9 format, 4 minutes). We don't make actual lie detectors...just educational stuff to illustrate the basic principles of their operation.
The video shows the kinds of body signals that are used in a polygraph that an examiner would look at to tell if someone's lying:
GSR - Galvanic skin response. Basically it measures changes in the resistance of the skin...it can tell if you're sweating. If you get tense, you sweat.
Respiration - Shows the expansion and contraction of the chest cavity (e.g. it expands when you breathe in, contracts when you breathe out...a flatline indicates you're holding your breath). Most people breathe in a regular rhythm. Changes from this rhythm may be an indication of tension or another change in breathing activity.
Heart rate - Extracted from the electrocardiogram. A faster heart rate indicates tension or excitement.
The text at the top of the video indicates what the person is doing when the red triangle appears above the data. They're a little blurred in the video, so I typed them below.
They start out with a list of tasks from simple to complex, illustrating how these three types of signals respond for things like talking and moderately difficult tasks (they wouldn't be used an an actual polygraph calibration). The 'questioning' period is at the end of the video and shows how these signals are used in a polygraph style situation.
The sequence of tasks at the top are
Say your name
Count backwards from 18 (speaking)
Count backwards from 38 by decreasing odd numbers
Touch face
Concentration on colored squares (e.g. no speaking, just looking at pieces of paper)
white
black
red
blue
green
yellow
orange
brown
purple
Answering "yes" or "no" questions
Are you a student?
Are your eyes blue?
Do you have brothers?
Did you last earn an A?
Do you drive a motorcycle?
Are you less then 25?
Have you traveled to another planet?
Have aliens visited you?
Do you watch seinfeld?
Have you answered truthfully?
Can you tell if this subject lied on any of the questions? As you can see, a polygraph is definitely not a machine that can kick out a definitive "he's lying". The key to tricking a polygraph is learning how to control your mental state and bodily functions so that you just always reproduce the nice no-stress style signals (kind of like how athletes can pace their breathing to control heart rate).
Disclaimer: This comment is personal and not any kind of statement by my employer. I just think this stuff is interesting and wanted to share...and I'm definitely no pschyophysiology expert and not a polygraph examiner:-)
I'm not quite certain where you're getting your launch information from...ever since the initial Alpha release OOo OS X X11 has shipped with AppleScripts that allow a single double-click to launch both the X server and application, no command line needed. Each copy now ships with Terry Teague's Start OpenOffice.org applet that does this as well as provide Finder document associations for double clicking documents directly and also drag and drop font conversion.
If you're a geek who wants to start it from the command line, you can, but steps have definitely been taken to make it accessible to people who have no clue what a Terminal is.
ed
M-audio released a new driver, version 1.2.7, yesterday that has support for the update if you installed it. It also adds 10.3 support along with 10.2.7 support for G5s according to the litle release note summary.
While X-Plane runs on many platforms, it is developed on Mac OS X. Closed vs. open source feelings about X-Plane aside, it really is a testament to the FreeBSD underpinnings of Mac OS X that such an accomplishment could be feasible.
Under Mac OS 9, cross-platform development was a bear. At least now it's more like a marmot with really sharp claws and a penchant for beef jerky or Trident in your pack.
Well, for simple files yes...but don't forget that it's possible to embed a spreadsheet in a Word document along with a few dozen tables, some calls to a database, charts, math equations, forms with buttons and actions, etc. Don't forget those lovely VB macros.
Competing with Microsoft Office requires a lot more then simply being able to open up the text of a.doc file. For simple tasks and basic file exchange a 80% accurate text component may be enough to let bob open up and look at alice's resume. For hardcore business work though, more is needed then simply rendering pretty antialiased text. Just as Word is not just a word processor,.doc is not just text.
Mac OS X (X11) 1.0.3 Final has been out for three weeks now, and it's been out of alpha since last October. If the review is correct and the CD contains the alpha version, I think the book is just a tad out of date.
If you're looking to get OpenOffice.org for the Mac, you should get the GM from the official download site and not use what's on the CD with this book. As the "GM" implies, there were lots of bugs fixed between the "Final Beta" and "GM", and definitely lots of serious issues were fixed since the alpha.
If you're on another platform, you should probably check the version on the CD as well. Even though it's now being called a "legacy build", the latest stable version is 1.0.3.1 which fixes nasty printing errors in 1.0.3 on other platforms (didn't happen on the Mac! woo hoo!). The "RC" in 1.1 RC stands for "Release Candidate", so if you're thinking of going the whole way to 1.1 you may want to wait until the RC is dropped from the name.
I guess, in short, don't buy this book just to get OpenOffice.org on a CD since you'll probably have to download a newer version anyway.
For those who don't know the acronym (no, it's not from the game) UNO stands for Universal Network Objects. It is essentially a home-brew component bridge, in a similar vein to Microsoft's COM or CORBA. It specifies a layer abstraction that allows components written in one language, say C++, to call code and receive valeus from components written in another language, say Java.
The importance of a Python bridge for UNO is that now individual parts of OpenOffice.org can be implemented in Python. While this is not likely (though it couldn't make OOo any slower...), the reverse direction is the most beneficial. Any Python program can now interact with a specific component of OOo, such as the Word filters, on a code level. In essence, you can now use Python to script OOo and also use parts of OOo in your own Python apps. This is good news for Python programmers.
Their code has been released only under the LGPL license.
To commit code back into OpenOffice.org, three things must happen:
The code must be released under both LGPL and SISSL (the "closed source is fine as long as you use the same XML schemas" license). Right now Ximian's source is available under LGPL only.
A Joint Copyright Assignment form must be on file giving copyright to your changes to Sun Microsystems.
You need to go through the fun patch submission process and politics of forcing your patches down Sun's throat.
As an example, all y'all linux, *bsd dudes could have had three-modifier (e.g. use Alt, Control, and Meta for keyboard shortcuts) but project politics kept these patches from being accepted into the source base. Silly that such a simple community-contributed feature wasn't accepted, no?
This patch submission difficulty is one of the reasons why Ximian icons and patches are not within OpenOffice.org. It's also one of the reasons the Tru64 patches never made it back into OpenOffice.org. The Tru64 team got 1.0.0 compiling, but the patch submission/approval process was so daunting they just didn't bother.
This is actually a problem for all open source projects...
There is no open source grammar checking library! At least none robust enough to provide any useful information.
Grammar checking is notoriously difficult...hell, back in the day there used to be companies like Casady & Greene (sniff...I liked their stuff) that made standalone grammer checkers like Grammarian. Many other companies with standalones went under, but their source code is now relegated to the sands of time.
The cloest thing I've seen to what may become a viable grammar checking library for open source is the Link grammar parser. It seems pretty good and has a online sample of what it can do, including some automated translation!
You can use this project for free in non-commercial applications. Alas, this runs afoul of the SISSL license used for OpenOffice.org since it explicitly allows for commercial products to be derived from the OOo source code (like StarOffice). It's also incompatible with LGPL and GPL, too, since it would place an additional restriction on how LGPL/GPL software is used. AbiWord has some bindings for the link grammar parser in its code, but they're not activated due to licensing restrictions.
About a year ago when I contacted the team, they said they were going to do a rereleas under an MIT style license or a GPL-compatible license, although thus far I've not heard anything since. Anyone know them and want to help set a few wheels in motion?
The other alternative is to add in a bridge to communicate with a separate process from a GPL licensed project, where the separate project is never loaded into the same address space and is under a non-commercial non-GPL license only. I've wanted to do this for NeoOffice and have sketched out rough APIs, but I haven't had the time to sit down and actually code it.
I don't believe the Debian maintainers (Chris) have Debian packages ready yet. You'll still have to grab the full "tarball" style installer and try to run it on a Debian system. It's only been tested on Red Hat, I believe, internally. Best bet is to fire off a message at Chris or to lurk on the dev@porting.openoffice.org mailing list to find out more about where the Debian status is.
I do know that due to OOo's dependencies on Java for building and compiling, not for running (it's C++ code, already. christ, look at the code you java complaining wankers), it may not move into the core Debian product until it can be built using Kaffe. I believe part of the difficulty (aside from the fact Java is, nor ever will be, free software) is that some of the Java-based build tools are using the 1.4 XML classes now as well as linking against the Java Accessibility Bridge. This makes it impossible to build on a pure free software system, even though it runs on pure free-software GNU/Linux systems.
This would normally be a sign that your code is getting a wee bit bloated.
Well, it's always been 'bloated', more in its startup time then anything else. When it starts up it needs to load like 100MB of shared libraries, as well as perform font caching on Linux systems, query the print system, etc. etc. etc. This code is really an example of how templates can be used for evil, not good, leading to the bloat.
It was already donated to open source in its bloated state by Sun/StarDivision, but it's much less bloated now then it used to be in StarOffice 5.2. It used to have its own implementation of a web browser in 5.2, for chrissesake.
That said, in 1.0 launch times can take upwards of minutes on some machines. So in essence, while the better solution in the long run may be to remove bloat, the progress bar is a welcome addition. I've had to do user support for a lot of newbies who are wondering if the software's really crashed after seeing the static splashscreen for 20 seconds, force quit the software, try launching again, waiting another 20, and so on like the the instructions on my shampoo. Seeing something happen or a progress bar that hasn't finished all the way wil at least let these users know that "yes, startup time is crap" instead of thinking "crap, it doesn't work and I need help".
And as to removing bloat once it's in there, look to Mozilla for an example of how successful it can be on an old crufty code base. And OOo is over four times as large. It'll definitely take time. Meanwhile, use ooqstart or change your work habits a bit (towards bottom of thread) to make getting to that word processing document when you need it now a bit snappier.
I'm not sure if Linus worked on it, but the new "quick-launch" functionality of OOo is directly due to cheating.uh.cleverness. It actually runs through and does page-in reads of all of its shared libraries into memory instead of doing them incrementally via the linker/VM manager. So in a sense, that, combined with any optimal way to avoid page-faulting those images out, should make OOo faster.
OpenOffice.org 1.1 RCs are not available for OS X. We just got it compiling a few days ago. And it'll require much more work then simply compiling it, such as testing, integration with the asian fonts and input methods, etc.
Want it faster? Well, there's only so much two guys can do. We just finished our first full Gold Master release just two weeks ago and man, we need a vacation!
Our OpenOffice.org Mac version is X11 based. It looks identical to using the Win32 version. It's functional, not pretty.
Its installer will help a Mac X11 neophyte through the process of setting up an X11 environment. It's also got the Start OpenOffice.org project to allow you to launch it like a normal Mac application and do document associations (e.g. double clicking an OOo doc opens it up!).
The Aquanative porting work is being undertaken in the NeoOffice project, not within OpenOffice.org. NeoOffice is a free software GPL version of OpenOffice.org.
Two native versions are in the works, NeoOffice (Cocoa) and NeoOffice/J (Java2D...only for UI, it's still 99% C++! It's the shoddy C++ that's slow, not Java!).
Because of political issues of submitting patches and difficulty modifying code owned by the gsl project, it's difficult to do this work within OpenOffice.org. We're also trying to take the project in directions that Sun doesn't want to take StarOffice, and OpenOffice.org really is just the StarOffice development team with its own motivations needed to keep their jobs...and helping a bunch of free software dudes isn't one of them. As sucn, there may unfortunately never be an official OpenOffice.org Aqua port with a true Mac UI.
We're moving NeoOffice up to 1.1, but have to get OOo compiling first. Not enough people are helping out to allow us to focus on the fun stuff, so we've got to do the grunt work as well.
We're working as hard as we can (c'mon, we're not paid!), and you should keep your pantyhose on. OpenOffice.org 1.1 Developer Preview for MacOS X shall be coming soon (e.g. we've had time to stop committing patches and make a really rough really untested binary). And also coming down the pike is another binary of NeoOffice/J with full Japanese support, both for input as well as localization!
I suspect if they wanted to they could build a large legal testing team that had valid channels to report bugs. Does anyone else remember that OS X 10.0 Beta program sold CDs to people to join the beta program for like $10-$20? It was right after DP4 (which was seeding program only, I think).
I expect they don't shut down the torrents not because they want beta testers, but just because the distributed nature of torrents makes them hard to shut down without a very active team of people trying to always find where they crop up. It's possible, but would require some human resources.
For folks with Panther seeds, IIRC it's recommended to feed in bugs through the user's ADC account radar/bugreporter. Note that ADC accounts also have records of e-tickets for WWDC 2003, so in theory it's possible to track individual 'illegal' users through bug reports too, so if you weren't at WWDC you may not want to report any you find.
Well, there may be more people who have Panther legally then just WWDC attendees. Apple does have a Software Seeding Program which has been around for years. While I don't have a seeding key to be a member of the program any longer, I expect Panther builds are part of it.
Not all WWDC attendees are necessarily in the seeding program to download updates to prelrelease software, so there is a valid reason aside from piracy tracking to put the update in Software Update instead of just in the seeding site.
Still, even if you are tempted to download and install illegally, or if you have it legally and are thinking of installing it on your main machine, there's a good reason not to use it except on test machines. Read the license carefully...one of the sections of the license implies that the OS and dev tools are time limited and will stop functioning after a certain date.
The only folks I can see this hurting are those who don't heed the recommendations of putting seed software only on test machines, or those who got Panther betas illegally and didn't bother to read the fine print.
There are also rumors that you will not be able to install 10.3 GM on a machine running one of the prereleases. A friend at a large company told me that their company recommended that their employees be very careful about where they install Panther previews and to not put it on their main work machines.
I'd conjecture that the workaround is to go back, reinstall a clean copy of 10.2, then put GM on there (or other OS when the preview expires). But no one can be certain until the day 10.3 GM comes.
Remember, Panther is beta software for testing purposes. Given what I've learned, I'd caution everyone to treat it as such.
OpenOffice.org does have its weaknesses when compared with Microsoft Office, one of which is documentation. Books like this help to address that, as well as leeching Sun's StarOffice documentation for free.
I think this all of the other detriments noted in the comments are to be expected when comparing a product that's been in development for near 20 years against a project that became open source only a few years ago. If you're evaluating OpenOffice.org as a replacement for Microsoft Office on Win32, chances are it will fail. It's much more then simply a Win32 Office replacement. For example, OOo has:
support of alternative platforms - Now users on Solaris, FreeBSD, Tru64, IRIX, DarwinPPC, LinuxPPC, LinuxARM, and other platforms still to come can use their computers in a corporate setting. I doubt Microsoft will ever release Office for any of those platforms.
Unicode support - Unicode is pervasive in the entire suite, and vertical/right-to-left language support is coming in 1.1. It can be diffiicult to do full Unicode editing in MS Office (at least on a Mac)
Language support - You can use OpenOffice.org on a Mac with the interface completely translated into Greek. There are other translations into languages like Estonian, with more being added each day. Microsoft probably won't translate Office into every language, and the entire world doesn't speak English.
Full XML support - XML support is a key in OOo 1.0, and uncompressed XML is in 1.1. And the schemas are public. One of the provisions of the SISSL license is that closed source derivatives, like StarOffice, must adhere to the public schemas. This means if you're doing a document content storage & retrieval system, you can store OOo XML documents without losing formatting as is the case with the Office XML exporters in development.
Free - Aunt Jane and Uncle Bob shouldn't be forced to pay $300 just to type a resume. And with the advent of Office XP product activation and Office v.X network licensing, it's nice to know there's an alternative that you can use to get your work done on time for a deadline even when your company's run out of licenses!
Open source - If you don't like something with it or want to enhance it, you can...if a bug is irking you, you can fix it...that is, if you're willing to trudge through the source. NeoOffice is an example GPL variant that is working to port to Cocoa, and other projects are underway to port to XUL and other platforms.
Is OOo ready to replace MS Office? No. For certain users, however, it provides options that simply didn't exist before OOo, and options that Microsoft will probably never provide. Complaints about OOo are fine and dandy, but don't overlook the strengths that it provides today and the options that it's given to thousands of users Microsoft has no intention of supporting.
One of the OpenOffice.org goals is actually to maintain an identical appearance across all platforms. This isn't necessarily the community's goal...but rather Sun's. That said...
If you're intrepid enough to compile the sucker (takes over a day) you'll find the icons are simply windows.bmp formatted files that you can replace with whatever you want. This results in the creation of an alternate set of.res files that you can then drop into any OOo distribution. This is the approach that Ximian uses to bundle a different icon set into their 'enhanced' OpenOffice.org included with Ximian Desktop.
It is also possible to use completely alternative widget sets with OOo, as illustrated by the NeoOffice port using Cocoa widgets and Carbon-rendered widgets (screenshots of Neo vs. Office v.X). This approach, however, is still only available to GPL versions of OOo.
If you've got better ideas as to how to achieve cross-platform compatibility and skinning while maintaining the identical look and feel requirement Sun has, stop by the Graphics System Layer project and lend a hand!
And if you're an intrepid graphics designer (who knows a few other intrepid graphics designers...) and would like to make an alternative icon set for the approximately 1000 icons, please pipe up and help us out! Parts of our icon set are the direct result of the truism that programmers are definitely not graphics artists, and others are relics from when Star Division was busy mimicing Win95/Office97. Our community development can only provide the features the community wants if folks volunteer, else OpenOffice.org will continue to gain only the features Sun believes are needed for selling StarOffice, not necessarily those wanted by the user base of its free cousin.
Dammit. Used PHPNuke URL syntax. Stupid form submission error:)
Try this link for BIOPAC Systems, Inc. Note that my comment above is not reflective of the position of my employer, but rather a personal exhortation so no one kills themselves doing this.
If you do try this at home, *please* be careful to put a *really good* surge protector between your computer hardware and yourself. One of the major flaws with this type of approach is that it does not provide ground isolation between the computer hardware and the human subject. If, God forbid, a power surge occurred somewhere in the system, it would be transmitted to the subject and result in electrocution. I work at a [url="http://www.biopac.com"]physiological research[/url] company, so have been made aware of the risks of interfacing humans with computers through direct monitoring electrodes. If research or medical equipment that is plugged into a power socket stands even a *remote* chance of being connected to a human subject, it must be appropriately designed to have an independent ground to avoid killing its subject in its worst case scenario.
For animal subjects, the approach of this article is perfectly safe depending on whether one cares or not that there is a statistical risk of killing the animal.
This argument applies for any medical equipment. Medical equipment design goes beyond accuracy or uptime...it's designed *ensure* that the person it's connected to cannot be killed by it. If you're attaching a wire onto your body that has even a remote chance of connecting to the power socket, beware.
Apple had some of the first truly 'silent' desktop
on
A Truly Silent Desktop PC
·
· Score: 5, Informative
Remember the PowerMac G4 Cube? Aside from all of its brouhaha on price, lack of expansions, etc., it was 8 inches square and was a fanless convection cooled machine (and still is, for those of us who still use them!), and 1-2 years before any of these fanless mini-itx form factor machines.
It really is perfect as an iTunes console/DVR at the side of the TV, but priced well above using one for that purpose at the time.
Similar to these mini-itx style boxes, the G4 Cube had internal hard drive and CD-ROM noise, but with NetBoot (or some optical FireWire repeaters and a hard drive in another room) you could run the sucker completely silent.
The only fan that was in Apple original designs was the video card fan for the ATI Radeon graphics cards (Rage 128s were fanless). Unsupported Radeon upgrades were fanless. Most upgrades these days to honk up the processor to a 1GHz+G4 single or dualie add in an 80cm fan at the base of the unit to push air through. Similarly with GF3s or other video cards put inside this case...convection alone isn't enough to cool the chips. Fans and noise will probably be the price of powerful machines in small form factors for some time to come given that minimal heat dissipation is not a primary design goal of high-end CPUs and GPUs.
No, simply using Aqua buttons does not a Mac application make. But what's the sense of having a Mac-like UI if it is drawing Windoze buttons, toolbars, and menus?
Slashdot Mirror
Slashdot is supposed to be News for Nerds, not Propaganda for Nerds. There are three sides to this story: SCO's side, the anti-SCO side, and the truth. Only one side is appearing anywhere on slashdot, and it isn't the truth.
IANAL, but I do wonder if this propoganda is actually incredibly relevant to the case. It seems like the core issues aren't really copyright law or IP law, but rather based in contract law. The various sides are essentially arguing different interpretations of contract language, both of the sale of Unix to Caldera and of the initial license contracts between AT&T and other Unix developers. So...assuming a judge/jury would find the language unclear...what would a judge/jury use to choose one meaning over the other?
I'd have to think that this propoganda that purports to show the 'original intention' of the language would be used as evidence to back up one side's specific interpretation of the text. It'd probably be even more persuasive to a jury of people who don't possess contract grammar parsers. If it's already being used so dramatically in the court of public opinion, what's to prevent it from being used in court itself?
ed
Mr. Ryan E. Tibbitts
General Counsel
The SCO Group
355 South 520 West
Lindon, UT 84042
Re: Sequent Computer Systems
Dear Mr. Tibbitts:
On May 29, 2003, SCO sent a letter to Sequent Computer Systems providing notice that it would terminate Sequent's SVRX license agreement as of September 2, 2003 if Sequent did not remedy certain alleged breaches of the license agreement. On August 11, 2003, SCO sent another letter to Sequent purporting to terminate Sequent's SVRX license agreement. IBM, on behalf of Sequent, responded to these letters by letter of August 14, 2003.
As it has with IBM and other SVRX licensees, SCO appears to be taking the position that code developed by Sequent, or licensed by Sequent form a third party, which Sequent incorporated in its UNIX variant but which itself does not contain proprietary UNIX code supplied by AT&T under the license agreement betwee AT&T and Sequent (Sequent Code), must nevertheless be maintained as confidental and may not be contributed to Linux. As we have said before, SCO's position defies both logic and the terms of the SVRX license agreement.
SCO cites, as support for its position, section 2.01 of Sequent agreement, which, like other SVRX licenses, provides as follows:
Such right to use includes the right to modify such SOFTWARE PRODUCT and to prepare derivative works based on such SOFTWARE PRODUCT, provided the resulting materials are treated hereunder as part of the original SOFTWARE PRODUCT.
As we have said, however, this provision merely confirms that AT&T retained ownership of its code even if it was incorporated in a derivative work, and does not purport to impose confidentiality or use restrictions on Sequent Code.
In fact, SCO's interpretation of 2.01 is plainly contrary to the position taken by AT&T, as author of and party to the SVRX licenses. AT&T clarified the meaning of section 2.01 in its $ echo publication, which AT&T described as its own newsletter to reach all UNIX System V licensees through one defined medium and keeps them abreast of any product announcements, policy changes, company business and pricing structures.
Specifically, in an edition of $ echo dated April 1985 (the same month that the Sequent license agreement was signed), AT&T announced that changes would be made to hte SVRX license agreement to clarify ownership of modifications or derivative works prepared by a licensee. AT&T said this and other announced changes were in response to direct feedback from AT&T licensees and [were] intended to make the contracts more responsive to the needs of licensees. AT&T then followed up by adding to section 2.01 a sentence clarifying that AT&T claims no ownership interest in any portion of such a modification or derivative work that is not part of a SOFTWARE PRODUCT. Even more clearly, the August 1985 edition of $ echo explained that this sentence was added to assure licensees that AT&T will claim no ownership in the software that they developed - only the portion of the software developed by AT&T. Copies of the April and August 1985 editions of $ echo are enclosed for your convenience.
For these reasons, and the reasons stated in our October 7, 2003 letter to you about IBM-developed code, SCO's position on Sequent Code is unsupportable.
Under Section 4.16(b) of the Asset Purchase Agreement, Novell retains the right at Novell's sole discretion and direction, to require SCO to amend, supplement, modify, or waive any rights under, or...assign any rights to, any SVRX License to the extent so directed in any manner or respect by [Novell]. That section further provides that to the extent SCO shall fail to take any such action concerning the SVRX Licenses as directed by Novell, Novell shall be authorized, and hereby is granted, the rights to take any action on [SCO's] own behalf.
Accordingly, pursuant to Section 4.16(b) of the Asset Purchas
and the Aqua widget set (usable from Objective-C, Java and C++ at least
While the Aqua widget set is accessible from a number of languages in the sense that the buttons look the same, the interfaces across the different languages definitely do not have the same level of parity. An example from Panther is metal buttons which are only accessible from Cocoa/Objective-C. Earlier versions of OS X even had more major interface elements unavailable to Carbon, such as sheets and drawers.
The underlying widget set of OS X has access from a very wide set of languages, but it's not yet fully language neutral in the sense that new widgets are automatically available in every language. Even though it's been getting better, the choice of APIs still places limits on which subset of the Aqua user interface elements can be used.
ed
I never really knew about how a polygraph worked until I went to work for a company that does physiology equipment and software for research and education. On our website is a video of polygraph data (caution, 5 MB, windows media 9 format, 4 minutes). We don't make actual lie detectors...just educational stuff to illustrate the basic principles of their operation.
The video shows the kinds of body signals that are used in a polygraph that an examiner would look at to tell if someone's lying:
The text at the top of the video indicates what the person is doing when the red triangle appears above the data. They're a little blurred in the video, so I typed them below.
They start out with a list of tasks from simple to complex, illustrating how these three types of signals respond for things like talking and moderately difficult tasks (they wouldn't be used an an actual polygraph calibration). The 'questioning' period is at the end of the video and shows how these signals are used in a polygraph style situation.
The sequence of tasks at the top are
Can you tell if this subject lied on any of the questions? As you can see, a polygraph is definitely not a machine that can kick out a definitive "he's lying". The key to tricking a polygraph is learning how to control your mental state and bodily functions so that you just always reproduce the nice no-stress style signals (kind of like how athletes can pace their breathing to control heart rate).
Disclaimer: This comment is personal and not any kind of statement by my employer. I just think this stuff is interesting and wanted to share...and I'm definitely no pschyophysiology expert and not a polygraph examiner :-)
I'm not quite certain where you're getting your launch information from...ever since the initial Alpha release OOo OS X X11 has shipped with AppleScripts that allow a single double-click to launch both the X server and application, no command line needed. Each copy now ships with Terry Teague's Start OpenOffice.org applet that does this as well as provide Finder document associations for double clicking documents directly and also drag and drop font conversion. If you're a geek who wants to start it from the command line, you can, but steps have definitely been taken to make it accessible to people who have no clue what a Terminal is. ed
M-audio released a new driver, version 1.2.7, yesterday that has support for the update if you installed it. It also adds 10.3 support along with 10.2.7 support for G5s according to the litle release note summary.
Under Mac OS 9, cross-platform development was a bear. At least now it's more like a marmot with really sharp claws and a penchant for beef jerky or Trident in your pack.
Competing with Microsoft Office requires a lot more then simply being able to open up the text of a .doc file. For simple tasks and basic file exchange a 80% accurate text component may be enough to let bob open up and look at alice's resume. For hardcore business work though, more is needed then simply rendering pretty antialiased text. Just as Word is not just a word processor, .doc is not just text.
If you're looking to get OpenOffice.org for the Mac, you should get the GM from the official download site and not use what's on the CD with this book. As the "GM" implies, there were lots of bugs fixed between the "Final Beta" and "GM", and definitely lots of serious issues were fixed since the alpha.
If you're on another platform, you should probably check the version on the CD as well. Even though it's now being called a "legacy build", the latest stable version is 1.0.3.1 which fixes nasty printing errors in 1.0.3 on other platforms (didn't happen on the Mac! woo hoo!). The "RC" in 1.1 RC stands for "Release Candidate", so if you're thinking of going the whole way to 1.1 you may want to wait until the RC is dropped from the name.
I guess, in short, don't buy this book just to get OpenOffice.org on a CD since you'll probably have to download a newer version anyway.
The importance of a Python bridge for UNO is that now individual parts of OpenOffice.org can be implemented in Python. While this is not likely (though it couldn't make OOo any slower...), the reverse direction is the most beneficial. Any Python program can now interact with a specific component of OOo, such as the Word filters, on a code level. In essence, you can now use Python to script OOo and also use parts of OOo in your own Python apps. This is good news for Python programmers.
You can read up more about UNO here.
To commit code back into OpenOffice.org, three things must happen:
As an example, all y'all linux, *bsd dudes could have had three-modifier (e.g. use Alt, Control, and Meta for keyboard shortcuts) but project politics kept these patches from being accepted into the source base. Silly that such a simple community-contributed feature wasn't accepted, no?
This patch submission difficulty is one of the reasons why Ximian icons and patches are not within OpenOffice.org. It's also one of the reasons the Tru64 patches never made it back into OpenOffice.org. The Tru64 team got 1.0.0 compiling, but the patch submission/approval process was so daunting they just didn't bother.
There is no open source grammar checking library! At least none robust enough to provide any useful information.
Grammar checking is notoriously difficult...hell, back in the day there used to be companies like Casady & Greene (sniff...I liked their stuff) that made standalone grammer checkers like Grammarian. Many other companies with standalones went under, but their source code is now relegated to the sands of time.
The cloest thing I've seen to what may become a viable grammar checking library for open source is the Link grammar parser. It seems pretty good and has a online sample of what it can do, including some automated translation!
You can use this project for free in non-commercial applications. Alas, this runs afoul of the SISSL license used for OpenOffice.org since it explicitly allows for commercial products to be derived from the OOo source code (like StarOffice). It's also incompatible with LGPL and GPL, too, since it would place an additional restriction on how LGPL/GPL software is used. AbiWord has some bindings for the link grammar parser in its code, but they're not activated due to licensing restrictions.
About a year ago when I contacted the team, they said they were going to do a rereleas under an MIT style license or a GPL-compatible license, although thus far I've not heard anything since. Anyone know them and want to help set a few wheels in motion?
The other alternative is to add in a bridge to communicate with a separate process from a GPL licensed project, where the separate project is never loaded into the same address space and is under a non-commercial non-GPL license only. I've wanted to do this for NeoOffice and have sketched out rough APIs, but I haven't had the time to sit down and actually code it.
I do know that due to OOo's dependencies on Java for building and compiling, not for running (it's C++ code, already. christ, look at the code you java complaining wankers), it may not move into the core Debian product until it can be built using Kaffe. I believe part of the difficulty (aside from the fact Java is, nor ever will be, free software) is that some of the Java-based build tools are using the 1.4 XML classes now as well as linking against the Java Accessibility Bridge. This makes it impossible to build on a pure free software system, even though it runs on pure free-software GNU/Linux systems.
Well, it's always been 'bloated', more in its startup time then anything else. When it starts up it needs to load like 100MB of shared libraries, as well as perform font caching on Linux systems, query the print system, etc. etc. etc. This code is really an example of how templates can be used for evil, not good, leading to the bloat.
It was already donated to open source in its bloated state by Sun/StarDivision, but it's much less bloated now then it used to be in StarOffice 5.2. It used to have its own implementation of a web browser in 5.2, for chrissesake.
That said, in 1.0 launch times can take upwards of minutes on some machines. So in essence, while the better solution in the long run may be to remove bloat, the progress bar is a welcome addition. I've had to do user support for a lot of newbies who are wondering if the software's really crashed after seeing the static splashscreen for 20 seconds, force quit the software, try launching again, waiting another 20, and so on like the the instructions on my shampoo. Seeing something happen or a progress bar that hasn't finished all the way wil at least let these users know that "yes, startup time is crap" instead of thinking "crap, it doesn't work and I need help".
And as to removing bloat once it's in there, look to Mozilla for an example of how successful it can be on an old crufty code base. And OOo is over four times as large. It'll definitely take time. Meanwhile, use ooqstart or change your work habits a bit (towards bottom of thread) to make getting to that word processing document when you need it now a bit snappier.
I'm not sure if Linus worked on it, but the new "quick-launch" functionality of OOo is directly due to cheating.uh.cleverness. It actually runs through and does page-in reads of all of its shared libraries into memory instead of doing them incrementally via the linker/VM manager. So in a sense, that, combined with any optimal way to avoid page-faulting those images out, should make OOo faster.
Want it faster? Well, there's only so much two guys can do. We just finished our first full Gold Master release just two weeks ago and man, we need a vacation!
Its installer will help a Mac X11 neophyte through the process of setting up an X11 environment. It's also got the Start OpenOffice.org project to allow you to launch it like a normal Mac application and do document associations (e.g. double clicking an OOo doc opens it up!).
Two native versions are in the works, NeoOffice (Cocoa) and NeoOffice/J (Java2D...only for UI, it's still 99% C++! It's the shoddy C++ that's slow, not Java!).
Because of political issues of submitting patches and difficulty modifying code owned by the gsl project, it's difficult to do this work within OpenOffice.org. We're also trying to take the project in directions that Sun doesn't want to take StarOffice, and OpenOffice.org really is just the StarOffice development team with its own motivations needed to keep their jobs...and helping a bunch of free software dudes isn't one of them. As sucn, there may unfortunately never be an official OpenOffice.org Aqua port with a true Mac UI.
We're working as hard as we can (c'mon, we're not paid!), and you should keep your pantyhose on. OpenOffice.org 1.1 Developer Preview for MacOS X shall be coming soon (e.g. we've had time to stop committing patches and make a really rough really untested binary). And also coming down the pike is another binary of NeoOffice/J with full Japanese support, both for input as well as localization!
I expect they don't shut down the torrents not because they want beta testers, but just because the distributed nature of torrents makes them hard to shut down without a very active team of people trying to always find where they crop up. It's possible, but would require some human resources.
For folks with Panther seeds, IIRC it's recommended to feed in bugs through the user's ADC account radar/bugreporter. Note that ADC accounts also have records of e-tickets for WWDC 2003, so in theory it's possible to track individual 'illegal' users through bug reports too, so if you weren't at WWDC you may not want to report any you find.
ed
Not all WWDC attendees are necessarily in the seeding program to download updates to prelrelease software, so there is a valid reason aside from piracy tracking to put the update in Software Update instead of just in the seeding site.
Still, even if you are tempted to download and install illegally, or if you have it legally and are thinking of installing it on your main machine, there's a good reason not to use it except on test machines. Read the license carefully...one of the sections of the license implies that the OS and dev tools are time limited and will stop functioning after a certain date.
The only folks I can see this hurting are those who don't heed the recommendations of putting seed software only on test machines, or those who got Panther betas illegally and didn't bother to read the fine print.
There are also rumors that you will not be able to install 10.3 GM on a machine running one of the prereleases. A friend at a large company told me that their company recommended that their employees be very careful about where they install Panther previews and to not put it on their main work machines.
I'd conjecture that the workaround is to go back, reinstall a clean copy of 10.2, then put GM on there (or other OS when the preview expires). But no one can be certain until the day 10.3 GM comes.
Remember, Panther is beta software for testing purposes. Given what I've learned, I'd caution everyone to treat it as such.
I think this all of the other detriments noted in the comments are to be expected when comparing a product that's been in development for near 20 years against a project that became open source only a few years ago. If you're evaluating OpenOffice.org as a replacement for Microsoft Office on Win32, chances are it will fail. It's much more then simply a Win32 Office replacement. For example, OOo has:
Is OOo ready to replace MS Office? No. For certain users, however, it provides options that simply didn't exist before OOo, and options that Microsoft will probably never provide. Complaints about OOo are fine and dandy, but don't overlook the strengths that it provides today and the options that it's given to thousands of users Microsoft has no intention of supporting.
If you're intrepid enough to compile the sucker (takes over a day) you'll find the icons are simply windows .bmp formatted files that you can replace with whatever you want. This results in the creation of an alternate set of .res files that you can then drop into any OOo distribution. This is the approach that Ximian uses to bundle a different icon set into their 'enhanced' OpenOffice.org included with Ximian Desktop.
It is also possible to use completely alternative widget sets with OOo, as illustrated by the NeoOffice port using Cocoa widgets and Carbon-rendered widgets (screenshots of Neo vs. Office v.X). This approach, however, is still only available to GPL versions of OOo.
If you've got better ideas as to how to achieve cross-platform compatibility and skinning while maintaining the identical look and feel requirement Sun has, stop by the Graphics System Layer project and lend a hand!
And if you're an intrepid graphics designer (who knows a few other intrepid graphics designers...) and would like to make an alternative icon set for the approximately 1000 icons, please pipe up and help us out! Parts of our icon set are the direct result of the truism that programmers are definitely not graphics artists, and others are relics from when Star Division was busy mimicing Win95/Office97. Our community development can only provide the features the community wants if folks volunteer, else OpenOffice.org will continue to gain only the features Sun believes are needed for selling StarOffice, not necessarily those wanted by the user base of its free cousin.
Dammit. Used PHPNuke URL syntax. Stupid form submission error :)
Try this link for BIOPAC Systems, Inc. Note that my comment above is not reflective of the position of my employer, but rather a personal exhortation so no one kills themselves doing this.
If you do try this at home, *please* be careful to put a *really good* surge protector between your computer hardware and yourself. One of the major flaws with this type of approach is that it does not provide ground isolation between the computer hardware and the human subject. If, God forbid, a power surge occurred somewhere in the system, it would be transmitted to the subject and result in electrocution. I work at a [url="http://www.biopac.com"]physiological research[/url] company, so have been made aware of the risks of interfacing humans with computers through direct monitoring electrodes. If research or medical equipment that is plugged into a power socket stands even a *remote* chance of being connected to a human subject, it must be appropriately designed to have an independent ground to avoid killing its subject in its worst case scenario. For animal subjects, the approach of this article is perfectly safe depending on whether one cares or not that there is a statistical risk of killing the animal. This argument applies for any medical equipment. Medical equipment design goes beyond accuracy or uptime...it's designed *ensure* that the person it's connected to cannot be killed by it. If you're attaching a wire onto your body that has even a remote chance of connecting to the power socket, beware.
Remember the PowerMac G4 Cube? Aside from all of its brouhaha on price, lack of expansions, etc., it was 8 inches square and was a fanless convection cooled machine (and still is, for those of us who still use them!), and 1-2 years before any of these fanless mini-itx form factor machines.
It really is perfect as an iTunes console/DVR at the side of the TV, but priced well above using one for that purpose at the time.
As evidence of a near-identical form factor, folks have managed to cram mini-itx motherboards inside its case.
Similar to these mini-itx style boxes, the G4 Cube had internal hard drive and CD-ROM noise, but with NetBoot (or some optical FireWire repeaters and a hard drive in another room) you could run the sucker completely silent.
The only fan that was in Apple original designs was the video card fan for the ATI Radeon graphics cards (Rage 128s were fanless). Unsupported Radeon upgrades were fanless. Most upgrades these days to honk up the processor to a 1GHz+G4 single or dualie add in an 80cm fan at the base of the unit to push air through. Similarly with GF3s or other video cards put inside this case...convection alone isn't enough to cool the chips. Fans and noise will probably be the price of powerful machines in small form factors for some time to come given that minimal heat dissipation is not a primary design goal of high-end CPUs and GPUs.
And for everyone complaining about the porting approach, I recommend reading that timeline's Aqua section which includes half a year for redesigning the interface to adhere to the Apple Human Interface Guidelines and will deviate from OpenOffice.org on other platforms.
No, simply using Aqua buttons does not a Mac application make. But what's the sense of having a Mac-like UI if it is drawing Windoze buttons, toolbars, and menus?
The link above should be http://www.neooffice.org.