It might be worthwhile to explore what it would take to make some variation of Lisp (*cough*sbcl*cough*) a workable choice for modern software developers. My own sense is that the major things lacking are a modern, powerful, cross-platform GUI and a general "lack of polish" (for lack of a better term) when it comes to interfacing with the rest of the world, but perhaps there are other fundamental issues? This seems appropriate:

Maybe it's time to drag them the rest of the way?

"That is a completely separate issue, however, from the way you've framed the question as to the legitimacy of why those plans are restricted from commercial republication."

Correct. I wasn't precise enough in my phrasing - what I meant was that while the presentation of the dimensions and information about the Wright airplane might be protected, (if I understand correctly) you are not even permitted to take the data itself (i.e. the actual physical measurements of the airplane documented in that presentation) and make your OWN presentation of that same data. Of course, that is a bit risky even if the agreement didn't preclude it - there is always a concern that the data may have been slightly "altered" to make it copyright eligible, similar to the question of whether map data are subject to copyright. Apparently (although IANAL) in the US the latest wisdom is that the actual physical layout of things on the map is not subject to copyright (since ANY accurate map would have to reproduce that exact same information, by definition - this is why it is thought commercial map makers occasionally add little non-existent streets or such into their maps - THAT work, being something other than a literal representation of reality (however close it may be) IS subject to copyright. See http://wiki.openstreetmap.org/wiki/Copyright_Easter_Eggs)

Remember how this really works - whatever the current laws, there will be pressure from commercial entities to pass protective laws solely for the preservation of the commercial potential of their products. Just as copyright is expanded as needed to protect commercial interests, so will the laws be expanded (if needed) to protect commercial interests related to 3D printing. The only "safe" items will be things that clearly are not a consequence of current "protected" products and are explicitly released under open licenses.

Of course, the article is quite correct that the statistical likelihood of companies going after any one individual for printing small numbers of parts is remote - even the music industry's campaign against file sharing has not made it all THAT probable that any given individual will be sued, it's just not cost effective to sue vast numbers of people who have no money and pay all the court costs. However, it DOES pose a problem for people who want designs that are fully legal in all senses of the word - i.e. those who want to use truly free models - and statistically unlikely doesn't mean some people won't get in trouble.

The patent/copyright issues surrounding this issue, while fascinating, are not the only potential problems. If someone prints a design for a car part they downloaded off the web and installs it in their car, and something goes wrong, would they try and go after the source of that model? More to the point, would they have a case if they didn't pay anything and no warranties were made as to the serviceability of the design? Some jurisdictions limit the ability to disclaim things like implied warranty: http://en.wikipedia.org/wiki/Implied_warranty Would the fact that the model in question was a free download and no money changed hands come into play? This is a point that comes up occasionally even in software - some people think they should have a right to have the tool work "for a particular purpose" even if they paid nothing to compensate the author for their work, although in practice this has seldom played out. Physical products based on designs are a more subtle problem - even if something goes wrong and money was paid, was it the design at fault or something else? How does one prove if the problem was the design, the printer, the plastic/resin used, the operation of the machine, improper use of the part, etc. etc. etc. IIRC, the Smithsonian makes people sign a waiver before they can get plans for the wright brothers airplane: http://www.nasm.si.edu/research/arch/collections/techdraw/wrights.cfm (Unfortunately these plans are quite restricted - no commercial use or redistribution, so what might have been an excellent source of high quality model plans is out of the question. I don't know if the dimensions in them are subject to copyright restriction - it seems unlikely but it would take a lawyer to figure out - but the agreement would seem to preclude anything interesting in that regard.)

That said, all human activity carries such risks. Authors of books (or for that matter authors of web pages!) run the risk of being sued for what their book motivated someone to do. People try to sue gun makers for what people do when they misuse guns. Anyone holding public office with significant power has painted a legal bullseye on themselves. Hopefully a free model community will eventually appear, the issues will be worked out, and we'll see a surge of scanning of historical artifacts outside of all possible copyright/patent concerns and new designs under open licenses. Not just for the fun and creativity, but because those are excellent ways to preserve and build on old designs from past masters.

The existing open CAD models are somewhat scarce, but some of those that do exist have gravitated toward the Creative Commons licensing schemes. I am aware of:

OpenMoko: http://wiki.openmoko.org/wiki/CAD_models under Creative Commons BY-SA - from a model quality standpoint, this is probably the best one I know of.

Via OpenBook: A laptop computer case. The original website doesn't seem to be there (anybody know what happened?), but there is a mirror here: http://bzflag.bz/~starseeker/CAD_MODELS/VIA_OpenBook/

There are a smattering of others - not sure what license these use:

Bug Labs: http://bugcommunity.com/wiki/index.php/Image:BUG_BASE_C_ASM.zip
RepRap: http://reprap.org/wiki/Mendel/SolidWorks
Elphel had some at one point, not sure where they are now on the site: http://www3.elphel.com/index.php

Hopefully these are harbingers of things to come - does anybody know of more good open source models?

There have been other projects over the years that have tried to improve on X (Fresco/Berlin and picogui readily come to mind) but I don't believe any of them have demonstrated results that seriously threatened the revitalized Xorg project.

I hadn't heard of Wayland, but I must admit since Xorg got going I haven't kept a close eye on that level of the graphics stack. Mark's blog post makes it sound like they're willing to ditch network transparency for better graphics effects, which makes me a little leery. Undoubtedly for most users that's the "right" approach, but if they do lose network transparency it's going to make Ubuntu an impossible choice in a lot of business environments where running apps from a server is part of day-to-day business.

Also, the amount of work to port all the requisite software/toolkits to a non-X platform is going to be... impressive. Haiku faces this problem, as do a fair number of older applications when looking at running native on Windows and OSX - it ain't easy. Plus, we're talking an entirely new backend in Wayland, one that's going to require (from the sound of things) rock solid OpenGL support.

Ubuntu has shown they can deliver in the past, and perhaps they can do it now, but I can't help but wonder if they realize the magnitude of what they're undertaking here.

Currently Qt requires copyright assignment (as I understand it) for code to become part of Qt proper. This is going to be a non-starter for a lot of open source folk. As I understand it,this was one of the biggest issues with the OpenOffice.org project in terms of community health, and one of the main drivers for LibreOffice. Qt has gotten away with it better because most of the things people want to do with Qt USE the toolkit instead of CHANGING the toolkit, but it remains a concern. As long as that restriction is in place Qt remains extremely dependent on Nokia continuing development. To date they've done an awesome job - Qt is arguably the best option for cross platform open source graphical application development out there - but longevity for open source is measured (at a minimum) in decades. Corporate good will is thin ice on those time scales - what if Oracle bought Nokia? Could "LibreQt" succeed as a community project without the considerable resources being funneled in by Nokia, if it ever came to that pass? (OK, the other side of this coin is that Qt is ALREADY essential to open source - that concern exists regardless, but it's something to think about in a move like this. Would putting the relevant kdelibs functionality in Qt result in less community familiarity with the code over time?)

Anyway, the KDE devs who wrote the code in question would have to sign on, and to me that sounds like a long shot. The other option - Qt devs implementing Qt versions of features currently in KDE and then KDE moving to the new stuff - sounds slightly more practical but would require a serious manpower commitment.

and misses the point. The variability of the kilogram standard is a scientific and engineering concern, not a political one.

Wikipedia discusses the issue: http://en.wikipedia.org/wiki/Kilogram#Proposed_future_definitions

In a nutshell - in order to create 1 kilogram physical standard masses, you have to first know what a kilogram IS. The physical standards referred to in the article do not appear to have retained constant mass over time. You can't define a constant based on something that is variable, so the current masses are (as I understand it) acknowledged to be an inadequate basis for the definition of the unit. The problem arises when you try to pick something to define it with that is both stable (i.e. a fundamental property of the natural laws of the universe) and practical (can actually create one to use as a practical mass standard against which you can prepare working standards.)

From articles that have popped up about this over the years, my guess is they will have to pick something as a basis and then work on various practical techniques to get as close to that ideal as possible - the question is what specifically to pick. N Carbon atoms? N Si atoms? What are the pros and cons when trying to physically create something that represents those numbers? How stable will a standard created according to a chosen standard be over time? (I.e., how often to we have to make new master standards? It's an important question - obviously the existing masses were not chosen with the expectation that their mass would vary with time, so how do we know to trust a given solution?)

So it's not the US objecting to the kilogram as a unit, but rather concern over the methods used to DEFINE the unit. That's something quite rational, not specific to the USA, and of scientific interest. Editors, how about changing the title to "US to Propose New Method of Defining a Standard Kilogram" instead?

Back in April '09 Schwartz sent an email out that touched on Oracle and Sun's employees. Specifically:

I suspect the most interesting point here is whether Oracle considers these departures to be a problem or not - the open source community obviously has its priorities and skill sets it would consider key, but Oracle may take a different view.

This seems like an inconceivably broad interpretation of any copyright law I am familiar with, but IANAL so perhaps there are some legal loopholes in UK law that allow this?

I would have thought copyright of a photograph would rest with the photographer (unless it's one of those cases where a building's design is considered copyrighted, but surely Stonehenge is beyond any conceivable copyright claims from the creators...)

I suppose there might be some kind of restrictions due to tricks (nighttime Eiffel tower is one example, I believe: http://en.wikipedia.org/wiki/Eiffel_Tower#Image_copyright_claims)

IIRC the UK allows copyright claims based on effort rather than creativity, so perhaps the effort to "maintain" Stonehenge in good condition allows some kind of copyright claim? (http://en.wikipedia.org/wiki/Threshold_of_originality#The_.22sweat_of_the_brow.22_doctrine) Seems unlikely to me, but it's not my field...

If this does result in a complete change in the way OpenOffice (or whatever it ends up being called) does project development, it's both scary and a big opportunity.

Risks:

1. Keeping up with document formats in Microsoft Office products is a difficult, time consuming process. Other open source office projects have never matched OpenOffice.org's support for MSOffice files, and arguably that strength alone is responsible for OpenOffice.org's success in the open source world. Implicit in that support is being feature-rich enough to be able to work with said documents, of course, which is also a lot of work. This kind of support, especially on something unsexy like office document formats, REALLY REALLY BENEFITS from paid people working on it. This is my single biggest concern going forward.

2. Code expertise. It has been years since I took a look a the OpenOffice code, but unless things have changed dramatically I have always heard that it was huge and required a LOT of time to become a productive contributor - definitely not organized into small, distinct parts. If the formerly paid developers can't devote their time to it as much/at all (which I wouldn't blame them for, we all need to eat) we could be looking at a substantial learning curve for the community.

Opportunities:

1. The relatively closed nature of the OpenOffice.org project seems, at least from my admittedly remote vantage point, to have resulted in a rather spectacular "not invented here" effect. OpenOffice has a great deal of functionality, but to the best of my knowledge there has never been any serious attempt to make independent libraries packaging that functionality for use in other applications - this is a shame. Perhaps even in principle you can't split office functionality up that way, but the KOffice team seems to have had some success doing so - perhaps this would be a good time to have an "XFree86->Xorg" style "break it into pieces" re-think of the OO.org architecture? Investigate whether and where it makes sense to break out OpenOffice functionality into libraries, contribute abilities to other projects' libraries and use those, or just flat out replace internal OO.org code with use of external libraries. Maybe OpenOffice really does need to be as huge as it is, but I'm rather suspicious of that.

2. REALLY hoping someone can make an OpenOffice fork/port/whatever that makes full use of the Qt toolkit. Instead of just getting the look of native widgets (which is what I understood efforts to date had been doing?) actually use the real Qt widgets and let the Qt toolkit handle that part of things. Probably requires major reworking of OpenOffice, but moments like this tend to be good times to take new directions like that. Let Qt do what it does so well and handle the cross-platform GUI widgets, and focus on the Office stuff.

Obviously not expert opinions as far as the OO.org codebase is concerned, and there may be reasons some of these things are bad ideas or won't work, but with luck and effort perhaps we can see actual major improvements (the integration of the Go-OO work is certainly a great start!) and some good will come out of all of this.

I don't see confirmation of this on the OpenOffice.org website - how "official" is this? The register article and the project website seem to indicate support from a lot of companies, but this seems to be quite the "bolt from the blue", so to speak - have there been rumblings of this behind the scenes?

From my standpoint, the two projects I was most concerned about when the Sun/Oracle deal was announced were OpenOffice.org and VirtualBox. There was a lot of noise about MySQL, but PostgreSQL is already out there as a very very viable (some would say better) alternative with a functioning community and long history. OpenSolaris never really became a major force in open source operating systems, so it's not likely to leave a bit hole. However, OpenOffice.org and VirtualBox both occupy highly user-visible spots in the open source world. OpenOffice.org has been absolutely key in breaking the "Microsoft Office" lock-in.

If this is for real the importance of this new project dwarfs the fate of MySQL. I really, really hope that enough resources are put behind the project to keep it viable and match compatibility with Microsoft Office, because if Linux no longer has the ability to easily read most Microsoft documents it will be one of the biggest hits to desktop viability that Linux distros could suffer.

Reminds me of the Helios prototype solar wing:

http://www.nasa.gov/centers/dryden/news/ResearchUpdate/Helios/index.html
http://www.nasa.gov/centers/dryden/news/FactSheets/FS-068-DFRC.html

When an industry is new, those skilled in the art are going to be thinking up lots of new applications, ideas and innovations as the "low hanging fruit" are plucked. The advent of internet commerce is a good example.

Or, as a thought exercise, let's say someone has just invented a practical, cheap maglev system using only permanent magnets. That innovation would deserve a patent. However, there are lots of obvious applications of a new system like that that would NOT need or deserve a patent in their own right. Conveyor systems on production lines and in warehouses with no moving parts or physical contact points to wear out, systems for moving material around in toxic environments with no moving parts in the toxic area, miniaturized versions sold as toy maglev trains (assuming the technology scaled), etc. Any mechanical system moving items would be a candidate for re-evaluation using the new technology. And I'm very far indeed from an expert in any such field - imagine what applications a REAL expert in those fields would come up with in just a few minutes. Would those ideas be patentable? Mine CERTAINLY shouldn't be - I'm not skilled in any such art and I whipped them off in a few minutes. There are probably a few obvious ways anyone familiar with such technologies would try scaling them - those certainly shouldn't be patentable under the obviousness criteria. But how would the patent system react?

The question, remember, is what is better for society - establishing monopolies for 20 years on the basic ideas of a new industry, or letting those early ideas spread widely and maturing the industry more quickly? Patents are only necessary if the innovations they disclose would be unlikely to appear in the intellectual commons via normal, unprotected business activity - the point of patents is to ensure disclosure for eventual common use of ideas that would otherwise be locked up as trade secrets - see Damascus steel. Innovations that cannot be duplicated by others skilled in the art are a high hurdle to jump, and in my opinion that's how it should be. People will innovate, with or without patent protection, because that's what people do to compete. The patent system thus needs to ADD to the public commons by allowing and encouraging more innovation to take place than would otherwise occur - otherwise it is a drag rather than a benefit. I'm dubious the system in its current form is a net gain, although I concede relative innovation rates between patent/no-patent scenarios is a difficult subject to acquire hard data on.

Can anyone point me to a good explanation of what is actually meant by this requirement for a patent (per wikipedia):

I would think that many of these questionable patents we see would run afoul of this requirement, regardless of other concerns. They seem to be using a rather low estimate of "ordinary skill" in the art for most things computer - it almost feels more like any idea at or above "ordinary" innovation in an industry is OK. When innovation and new ideas are the norm in an industry, I would hope the bar for non-obvious would be correspondingly higher.

Of course, all the financial and political incentives are geared toward granting more patents and letting the courts sort things out - I doubt many political figures would even consider not-for-profit innovation and development as legitimate or sane activities. I wonder some days if the state of the patent office isn't more a symptom of how our society values (or doesn't value) non-monetary pursuits and motives - if the only legitimate activities involve money, why not grant the patents and let them get sorted out? That way someone always makes money, even if its only the lawyers and the patent system - if they protect the non-commercial not-for-profit intellectual commons, who makes money there? Maybe I'm too cynical, but with even academic institutions diving head first into the "monetizing of knowledge" the ideal of knowledge for its own sake gets kinda hard to find.

I have some experience with Docbook, although probably not enough to qualify as an expert. From what I've seen so far:

Pro:

1. Generating pdf, html and (sometimes) man pages from a single source document. This is probably the biggest single win for Docbook.

2. Combining parts of documents with xinclude. If you have four documents of different types which need to contain the same introductory description of a tool (say) or a synopsis of command arguments (book, man page, short article, comprehensive encyclopedia, etc...) you can write the description once in one document and xinclude that specific piece of the document in other documents.

Cons:

1. Toolchain. TeX distributions get this right - install texlive with all the packages and you're done - you can handle any LaTeX document. For Docbook, it's a struggle to figure out what you NEED, never mind how to install it. Once you get it worked out you can integrate it into your build system and forget it, but it takes a while to get there.

2. You need to learn a lot of languages to customize the look of your output documents, and it's not exactly for the faint of heart. I suppose this is kind of a wash between TeX and Docbook, since both don't invite casual tinkering with the look of output, but it's a bit scary. I believe the Firebird RDBMS manual is an example.

3. Finding the "right" tags for what you're trying to do. Price of doing business of course, but there are a LOT of tags to sort through.

LaTeX of course mops the floor with Docbook when it comes to things like mathematics or pstricks, but to be fair about it that's not what Docbook was intended for.