Looking forward to 2007 [LWN.net]

Predictions, as they say, are hard - especially when they involve the future. It's easy to get them wrong and look like a total fool. Your editor, however, has long since gotten over his fear of coming across as a total idiot in front of large numbers of people; when you have already tipped your hand, there is no point in holding back any longer. So here's a few things which, in your editor's view, might just come to pass in 2007. As always, these predictions come with no warranty whatsoever.

Legal issues

Version 3 of the GPL will be adopted, perhaps after one more draft round. Your editor has no clue of how the FSF will respond to the criticisms of their anti-DRM provisions. If that language remains, uptake of the new license will be somewhat lower; the FSF may try to avoid that scenario by making "distribution on restrictive hardware without the associated keys" an optional permission which can be granted by the copyright holders.

Somebody will be sued for distributing proprietary kernel modules. Threats of lawsuits have been muttered for some time, but the late-2006 discussion on banning those modules made it clear that GPL infringement suits are the strongest weapon available to those who oppose proprietary modules. Given the way the frustration level is rising, it is only a matter of time until somebody uses that weapon.

We will see the end of SCO in 2007. Chances are that the company's case against IBM will not even survive until the planned trial date in the (northern hemisphere) fall. Look for fun around March, when dispositive motions can be heard.

There will be serious talk of patent reform in the U.S. The EFF is unlikely to succeed in its attempt to get the U.S. Supreme Court to throw out patents on software altogether; the current chief justice places a heavy emphasis on deciding no more than the current case requires, and software patents are not at issue in that case. But the pain caused by these patents is severe and growing; something will eventually have to be done. Whether that "something" will help to lift the clouds of legal uncertainty from free software remains to be seen, however.

Development

Linux will have fewer problems with closed hardware one year from now. There is already a clear path to support for most wireless network adapters. On the video front, a palpable determination to address the problem has come together over the last year. The Nouveau project can be expected to make significant progress over the next twelve months, and developers are beginning to talk about a project to support ATI's R500 engine. A decision by AMD to open up ATI's hardware would be a nice bonus. But, either way, the need to solve this problem is well understood, and developers are increasingly interested in attacking it.

Closed hardware problems will not go away, however. The content industry, with Microsoft's help, is pushing for a new generation of hardware which is intended to be "trusted" not to give too much control to its owner. "Trusted content paths" are fundamentally incompatible with free software. So we will continue to have trouble in carrying out straightforward tasks - like watching movies - on our free systems until the industry comes to its senses.

The war on bloat will get serious as people get tired of running out of memory. The increasing use of Linux on small and embedded systems will also create pressure for lower resource usage. Tools are emerging which will help developers track down wasted memory; their employment should lead to leaner systems for all of us.

The previous item notwithstanding, Java will move into the free software community as Sun follows through on its promised code releases. Thus far, the amount of free software written in Java has been relatively small. Once free Java support is available for all Linux systems, the number of developers of free Java code can be expected to grow.

Fedora will come into its own as a free, community-oriented distribution. Fedora's transition from a corporate product into a community product has been slow at best, and it is far from complete. The right things are happening, however; the combination of a more open process, a 100% free software policy, and a high-quality base should lead to good things.

Debian will get the Etch release out this year. Honest. What could possibly go wrong? Thereafter, the Debian developers will go back to arguing about firmware in the kernel.

Free software will move into online gaming as a critical mass of interested developers comes together. Many of the necessary pieces exist now as free software, and the possibility of acquiring some cast-off corporate code still exists. Meanwhile, Second Life has shown the possibilities inherent in hackable online platforms. These environments are too much fun - and too much a part of our future - to leave to the proprietary software companies.

Commerce

The Microsoft/Novell deal will blow over with few consequences. Most of the angry ink has already been spilled, and it still seems unlikely that Microsoft will launch a patent attack against Linux. Novell will have lost credibility in the community, and may yet lose more developers, but it has not really changed the nature of the patent threat.

The "open source" term will take a beating as various semi-open companies try to look like free software operations. Some companies have already needed to be told to take the "open source" label off their code; others will certainly follow. The need felt by these companies to attach non-free provisions to their licenses may lead to the creation of a "shared-source"-like replacement term by the end of the year.

The first round of OLPC systems will be distributed to millions of children in the developing world. That much can be predicted by looking at the project's timeline. Much harder to predict is what will happen when millions of children learn to use systems which are open, Linux-powered, and network-connected. This project may well change the free software community - and the world as a whole.

Desktop Linux will grow as corporate managers realize they already have more desktop systems deployed than they had thought.

As always, these predictions will be reviewed in December of this year.

(Log in to post comments)

Thus far, the amount of free software written in Java has been relatively small.

Posted Jan 4, 2007 13:14 UTC (Thu) by Dom2 (guest, #458) [Link]

I think it's mostly down to the fact that you don't have a central repository like CPAN for Perl. There is a lot free java software, but it's extremely disparately strewn across the Internet.

There are a couple of good places to start though: apache; codehaus; sourceforge.

Thus far, the amount of free software written in Java has been relatively small.

Posted Jan 12, 2007 10:45 UTC (Fri) by quintesse (subscriber, #14569) [Link]

And of course JPackage for RPM based distros.

Niggling edit

Posted Jan 4, 2007 12:37 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Or, as with the joke about the roof, was that one over my head? ;)

Looking forward to 2007

Posted Jan 5, 2007 15:50 UTC (Fri) by k8to (subscriber, #15413) [Link]

You will be able to buy that card in the relatively near future, and eventually you might be able to use it as your videocard.

It's essentially a brainless videocard (FPGA powered), and the FPGA load isn't done. So you could buy it now and hack, or buy it now and hope, or wait and buy it when they have something usable.

Something vaguely usable will probably happen sooner, while something snazzy will probably take more time.

The ASIC version will probably cost less and offer more performance, so many people will probably wait for that, which can only be made once they've hammered it out with the FPGA board.

Looking forward to 2007

Posted Jan 4, 2007 18:04 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

Or, you could just lighten up and get a sense of humor... Which, you might
find, will be a lot easier task to accomplish than getting everyone else in
the world who says anything you perceive as offensive or annoying or
insulting to stop doing so... Nevermind the fact that there IS a right to
freedom of speech, but there ISN'T a right to not be insulted/offended...
But, even if one were to concede to people like yourself who think they
have the right to tell others what they can and can not say to them (at
least you did say "please", rather than make it a demand as some do), it's
simply impractical and silly, and you're doomed to failure if you persist
in such an approach to the problem... Surely, you can see that? But, you
know, that's only even really relevent in the case of REAL insulting and
offensive remarks, which are indisputably and clearly intended to cause
offense... This remark doesn't even come close to living in that realm...
It's a joke... Humor, you know... Perhaps you've heard of it?

Looking forward to 2007

Posted Jan 4, 2007 18:35 UTC (Thu) by amikins (guest, #451) [Link]

Your irrationality posing as a "comment" is insulting. Please retract it.
(Yes, I know I shouldn't take the bait, but it was irresistable)

Looking forward to 2007

Posted Jan 4, 2007 18:37 UTC (Thu) by bronson (subscriber, #4806) [Link]

It's actually really funny. Ah, that dry Corbet humor.

We've participated in a lot of firmware flamage have we, yoe? :)

Looking forward to 2007

Posted Jan 4, 2007 18:59 UTC (Thu) by yoe (subscriber, #25743) [Link]

It's been pointed out to me that this wasn't actually a news item; rather, it was a prediction. In that light, I was mistaken.

I originally read this as a sarcastic remark, somewhat like "hey, they never get there anyway, so why do they bother at all?" which, to this Debian Developer, would be insulting. As it is a prediction, however, the context is different, and thus shouldn't be seen as sarcastic.

I'll go fix my bugs now.

Doug, he used... sarcasm

Posted Jan 5, 2007 11:11 UTC (Fri) by man_ls (subscriber, #15091) [Link]

I think it is a sarcastic remark, but I read it differently than you... something like: "it is without doubt an important issue, and a sensible solution should be sought; but the debian folks are so entrenched in their positions that I doubt they will ever reach consensus". See e.g. this article.

It is your choice to feel insulted by such a line, in whatever interpretation. I would selfishly prefer that you save your energies to fix bugs and keep making Debian the (IMHO) best distro in the world.

Looking forward to 2007

Posted Jan 5, 2007 1:19 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

with the vendor rewriting the proprietary portion of the module to not call any kernel functions.

I don't think that would have much effect on the derivative work argument against closed-source LKMs. If the proprietary portion's only purpose is to extend a Linux kernel, I don't think it matters how indirectly it calls Linux code.

But the Linux module for loading FreeBSD drivers would probably deal with it.

Looking forward to 2007

Posted Jan 5, 2007 4:18 UTC (Fri) by iabervon (subscriber, #722) [Link]

The "purpose" of a work is not relevant to copyright law at all. The aspect of a work as being useful at all only matters to trade secrets and patents. From the point of view of copyright law, the module is a product of creativity which may be have been created using the information in the kernel (i.e., if you're calling functions from the kernel, your choice of code is due to looking at the kernel). If the module only calls functions from some API that the vendor made up from scratch, it's not a derived work of the kernel, even if the only way the module could be made to run with code that has been written is by using the kernel, because the fact that it runs at all is merely incidental.

The reason to use FreeBSD's driver API would be that the module would then clearly not be a derived work of the Linux kernel, in that it would be completely intuitive to have written the module having never seen the Linux kernel, since the choices could clearly be motivated by the FreeBSD kernel.

Avoiding copyright violation with closed source modules

Posted Jan 5, 2007 8:27 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

The definition of derivative work, in the US at least, is quite hazy and as applied to computer code is basically up for grabs. But one of the arguments I see applying it to Linux modules makes usefulness quite relevant. It says a module is a derivative work of Linux because it is based on Linux in that its entire reason for existing is to be part of Linux -- it's an integral part of an expanded Linux. People with this view say the code being useful in multiple environments is therefore a litmus test.

But looking at your definition, where seeing and getting information from the Linux source code is the key, I don't see the distinction between the Linux-specific isolation module and the FreeBSD interface. In fact, you don't even need the isolation module; you can just have someone describe the Linux interface in prose and write your closed source driver without ever having seen Linux source code.

And one other thing about the isolation module: Don't the smart closed source drivers already do that? There's a better reason than legal for it: it lets people adapt your driver to myriad variations of Linux base kernel that you couldn't practically keep up with yourself.

Avoiding copyright violation with closed source modules

Posted Jan 5, 2007 9:48 UTC (Fri) by jschrod (subscriber, #1646) [Link]

It has been reported several times, the "smart closed source device drivers" like Nvidia's use isolation modules (shims) because their proprietary binary part is not Linux-specific but is designed to work on other x86 operating systems (most important, Windows) as well. The open source part maps the Linux API to the proprietary Nvidia API. (See, e.g, http://lwn.net/Articles/206435/)

If that's true, the legality of Nvidia's kernel module is not a settled thing, as it can be argued with good reasons that it's not derived code. Therefore, I would not hold my breath that someone sues Nvidia, it would be hard to make that a good case law.

Joachim

Avoiding copyright violation with closed source modules

Posted Jan 5, 2007 9:51 UTC (Fri) by kleptog (subscriber, #1183) [Link]

The other argument I've heard relates not to the source, but to the compiled binary. The point being that you compile the module, you need the kernel source. And the resulting binary object is a derived work of both the original source and linux kernel headers.

It's at least true that strings that only appear in the kernel headers end up in the final binary object, but is that enough to make it a derived work? If the Linux kernel headers are GPL, is the resulting module distributable?

That's why shim modules are safe, because the actual module no longer needs the linux kernel source, but the shim module which does can be under a licence compatable with both the linux kernel and the actual module.

Avoiding copyright violation with closed source modules

Posted Jan 5, 2007 19:31 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Yeah, the header argument is another one, but not as interesting because it is so easily circumvented: just don't use the distributed header files. Write your own that effect the same interface.

One thing that is clear in derived works of software is that when you compile from source, the object code is a derived work of the source. It was decided long ago that this is the same as translating from English to French, which is classic derived work.

But insofar as that's a pretty shaky analogy (because of the fact that software is much more than an exposition of ideas -- it's more like a device), I suppose a judge looking further might find that mere declarations (as from a header file) aren't really present in the object code, so the object code isn't a derived work of the header files.

And it might be a fair use exception, like how quoting a book is.

Avoiding copyright violation with closed source modules

Posted Jan 6, 2007 6:56 UTC (Sat) by roelofs (guest, #2599) [Link]

I suppose a judge looking further might find that mere declarations (as from a header file) aren't really present in the object code, so the object code isn't a derived work of the header files.

Or he/she might simply find that the header files aren't copyrightable in the first place, to the extent that what they embody can be expressed in only one way. (I seem to recall a statement, if not a ruling, to that effect in the SCO mess w.r.t. some AT&T errnos or something.)

I freely admit that's not very firm ground on which to stand once you include struct definitions in there--although I vaguely recall some further exceptions if said structs (and function interfaces) implement a public API?

Anyway, IANAL, so don't mind me...

Greg

Avoiding copyright violation with closed source modules

Posted Jan 6, 2007 14:02 UTC (Sat) by kleptog (subscriber, #1183) [Link]

If a header file only consisted of declarations, maybe. But the linux kernel header files are stacked with inline functions and macros, whose code will be copied to the final object. These functions and macros may contain references to strings, which will also be copied verbatim to the final object. There are also inline assembly blocks.

Now, if someone went through the header files and removed all but the parts that are just declarations or trivial macros that could only be written one way, you'd probably be fine.

But I think a blanket statement that all header files are uncopyrightable is I think going a bit far. It's trivial to disprove (move all your code to the header file, and include it). As far as the C compiler is concerned, there are no header files, that's the preprocessors job.

Avoiding copyright violation with closed source modules

Posted Jan 7, 2007 21:14 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

one interesting tidbit from the SCO/IBM lawsuit that I noticed recently

Moreover, the term "derivative work" is defined by federal copyright law, and one work must be "substantially similar" to a preexisting work properly to be considered a "derivative work". (Ex. 181 ¶12.) The mere fact that a product contains some licensed source code from another product does not make the product a "derivative work" of the other.

http://www.groklaw.net/article.php?story=20061222212643457

if this is correct mearly including some code may not be enough

Avoiding copyright violation with closed source modules

Posted Jan 8, 2007 1:16 UTC (Mon) by giraffedata (subscriber, #1954) [Link]

Well, the header file argument isn't that including the header files makes the binary device driver a derivative work of the kernel. It's that the binary device driver contains within it a derivative work of the header files, in the sense that object code is a derivative work of source code. So if you distribute the entire binary driver, you're distributing the header file object code and the copyright owner of the header files gets to control it.

But the header file argument isn't what most people use anyway; they use the derivative work argument from the top of this thread which doesn't involve use of any literal Linux code at all.

SCO's derivative work claim is even more tenuous than the Linux device driver one. It's a William's Axe argument that SCO owns parts of Linux that never had any relation to SCO-owned code.

(A museum somewhere in England has in its collection the actual axe used by William The Conqueror in battle, and by many of his successors. It is so old that between the time of William's death and the time it was preserved in the museum, the handle had been replaced 3 times and head 4 times).