F-Spot Considered Harmful

Quoting: So --- where's the beef?

Between the buns. You asked where the illegal thang came from, I answered.

Ah. You weren't presenting it as proof of correctness, merely source. Gotcha.

Quoting:This, I believe, describes nvidia drivers. It also describes ndiswrapper.

Yes, and it does not describe a closed source kernel driver. Which is what we were talking about and which GKH and many others say are simply not legal. A closed source driver necessarily incorporates a whole bunch of kernel headers otherwise it could not be loaded by the kernel.

Also note that many kernel hackers merely tolerate the "split driver"option from Nvidia, ATI and the like because it is proved that the binary blob that sits outside the kernel is not just Linux-specific. Nvidia uses the exact same blob on Windows for example. The devs have said that such split kernel drivers would be contested if it is clear that the binary blob is just for Linux.

dino, I understand that it's a legal gray area, and the finest minds of our time will happily argue it until the sun grows cold. It seems the definitive solution is "user choice," since lawyers and courts are incapable of giving definitive answers to anything except "Waste more time and money, kthx." For me it's simple-- I value 'free as in freedom' and don't want closed binary stuff. If I did I would run Macs.

@tuxchick I agree... If I was willing to accept closed binary stuff I'd also pick MacOS X over Windows... Although I have compromised that in a few areas like nVidia drivers... but that is just about it.

I've also been thinking about some of the points vect raised, and wouldn't be so quick to dismiss them. I've written about FOSS and money before, and the issue of respect, and gotten thoroughly massacred for it. Maybe there were lots of readers out there nodding to themselves and thinking yes, I see your point. But they didn't tell me or anyone else. If we gauge by the public discourse, FOSS is a realm of juvenile mouthy unprofessional asshats. If money is the coin of the realm, and respect the coin of the realm when there is no money, on the surface it appears that FOSS fails on both counts. It appears that coders are revered for no good reason other than a cozy self-congratulations club, while other contributors and users are lower life forms.

I'm still thinking it through.

> The devs have said that such split kernel drivers would be contested if it is clear that the binary blob is just for Linux.

I can't see any real basis for doing so, but if they want to try, it's their time and money.

Quoting: Can somebody explain this to me in a way that has more to do with the law than it does with mouth-breathing repetition?

Yes, binary blobs that are part of kernel tree are not legal.

Quoting: If the end user compiles them together and loads them up into the kernel, he or she is doing somethign explicitly allowd by the GPL.

No one is contesting this.

Quoting: Picture a driver in two parts. One part speaks to the other via a well defined api. One part is proprietary, the other is GPL'd. The GPL'd part of the code is a wrapper tha provides an interface between the Linux kernel and the proprietary core. The proprietary core contains no GPL'd code whatsoever.

One would say that this can then be done for most GPL'd code especially libraries and others that provide an API. Dynamically load GPL'd code in proprietary code (which VMs like java do automatically all the time anyway) and the same scenario as above is easily replicated. I doubt this would be considered a valid use (or else we would not have LGPL) though, of course, one cannot say for certain. My reading has been that anything short of two separate processes will constitute a derived work.

Krisum -

A derived work has a very specific legal meaning. It is the end result of altering a copyrighted work, whether by addition or subtraction. It has nothing whatsoever to do with the processes by which those changes are made.

As to being legal, repeating an unsupported conclusion does not an argument make.

Sander -

The law on header files tends to support the position that they are not copyrightable, except perhaps for verbatim copies that include comments. "Tends to" is the operative part of that statement -- it's possible to make headers that match program code for complexity and creativity, but that is not the normal case.

So -- it's possible that a kernel driver could be compiled with header files and still not violate copyright law. If that is the case, the GPL doesn't matter because the rights required do not require reliance on the GPL.

And -- as to contesting split drivers, people say they will contest a lot of things. Has nothing to do with the merits of whether they should bother.

Quoting: It is the end result of altering a copyrighted work, whether by addition or subtraction. It has nothing whatsoever to do with the processes by which those changes are made.

Well, I am in no position to contest that. However, as pointed out your example applies equally well to all GPL'd code so that all GPL'd libraries etc. can be used inside proprietary code to the extent that LGPL will be useless. I doubt this is the case and most likely not the intention of GPL though, of course, legally speaking it may be otherwise.

Quoting: As to being legal, repeating an unsupported conclusion does not an argument make.

At least for binary blobs inside the kernel tree, the situation is mostly clear cut.

edit: FSF's position has been that dynamically linking applications to libraries creates a single work derived from both the library code and the application code and though the GPLv2 does talk about collective works, this has been debated a lot all over and there is no point in doing that here again especially given that I have hardly any training in legal matters. I tend to go by FSF's interpretation of their license.

I'm not sure about headers dino. For userspacekernel interoperability it's probably not copyrightable. But modules and the kernel innards are very, very Linux specific. It would be impossible to recreate then from scratch without looking at or copying from the GPL kernel headers.

Krisum --

Not exactly. LPGL'd code can be distributed. The freedom to use GPL'd code as you wish is great if you have the coders to do what you want, and have no desire to distribute your work.

FSF's position is correct, but so what?

It is exactly the same thing I said. But note - their position is not that the driver is a derived work. It is the combination of the two that is a derived work, and the two are combined by the user, who, as has been made painfully clear, over and over and over again, is free to do that.

That has nothing to do with the legality of creating a driver, only with the freedom to distribute that driver in specific ways. It also means nothing to the copyright holder, who does not rely on GPL rights, or to others who have been granted rights by the copyright holder that go beyond what the GPL provides.

Quoting: It is the combination of the two that is a derived work, and the two are combined by the user, who, as has been made painfully clear, over and over and over again, is free to do that.

Yes, it is the ability to distribute the drivers with the kernel (as part of linux distributions, for example) that is in question here.

I made two points: * the model for development of out of tree kernel drivers you suggested is not much different from linking to a GPL'd library so it will likely have the same restrictions * in kernel tree binary blobs are not legal

If you change your second point to "may not be", then you're ok. Copyright holders, or those who have been granted appropriate rights by copyright holders, are not bound by restrictions in the GPL because their rights are not granted by the GPL.

I am presently at a disadvantage because I don't recall the specific terms under which contributions to the kernel are accepted. I know there is some requirement to disclaim patent rights, but I don't know what else.

As to development model, the scenario I provided is not restricted in any way by the GPL. It is the domain of the developer and the rights granted to the developer under copyright law.

Quoting: Yes, it is the ability to distribute the drivers with the kernel (as part of linux distributions, for example) that is in question here.

That fully depends on dino's interpretation that the kernel header files are not copyrightable. I'm still not convinced of that.

TuxChick,

Thank You for being objective about considering those things. I recently read some of oswald spengler's writings and they have influenced me to consider that problems in OSS may not originate with OSS. They may be tangible symbols of something else at this stage in our 'western' culture.

Hkwint:

I'm no longer very convinced. The examples you bring forward are extraordinary examples involving extroadinary people/scenarios whose experience with open source is not the same as ours is. Also, the fact that there are some bad commercial softwares doesn't really refute any of the points made about OSS.

Sander - I don't know the answer to that, either, and the answer may well be some are and some aren't.

A number of things are pretty common across unices and I will bet that no competent judge would find those things to be copyrightable beyond a thin protection against verbatim copying. Some things, maybe not.

Well If I could replace it with DigiKam on my Ubuntu rig I would, I never really liked it, but for reasons that have nothing to do with Mono. But DigiKam doesn't seem able to mount my iPhone camera, so F-Spot stays.

dino: True. That's why I said above that any headers needed for userspace and kernel interaction probably aren't copyrightable. It just looks way too much like SysV. But we're talking about kernel modules here. That's a completely different API and very Linux dependent. It's the kernel's internal API, the interface to it's subsystems, schedulers, memory allocators, etcetera. It looks nothing like SysV or BSD or anything else out there.

It's that internal API that kernel modules use.

Perhaps you were thinking of the SCO trials and the SysV headers when you were thinking about uncopyrightable header files? Those headers are part of the external API. The API that userspace programs use. It's a completely different API (and different set of header files) that the internal API that kernel modules use.

Sander -

Well, I'm really thinking of a general case -- which can make fools out of all of us.

There have been some court cases -- and some EU rulings (pertaining to monopolies, I think) -- that straightforward collections of structures that define an API for passing data in and out of a piece of software don't rise to the level of creativity required for copyright.

That level is a pretty low bar, though, and I can easily imagine headers that could meet it.