Harald Welte on the flood of GPL violations [LWN.net]

Bundling and the GPL

Posted Jun 20, 2006 14:21 UTC (Tue) by sepreece (subscriber, #19270) [Link]

There's also a fair chance that the distinction would be held to be irrelevant, under de minimis considerations. However, that could be taken either way - either bundling might be held allowable because it was not meaningfully different from post-installation download or post-installation download might be held not allowable because it was not meaningfully different from distribution-as-one.

When GPLv2 was released, the distinction did make it somewhat harder to create a product with an integrated free/proprietary binary running on it. In today's world it's much less hard - many devices and software packages are normally expected to update themselves when installed and the installation technology makes it relatively simple for manufacturers to meet the separation requirement, at least for devices designed to connect to networks. As a result, including the restriction in the license is largely pointless, today.

The more interesting question, today, is "what is a derivative work." If using interfaces made something a derivative work, then its distribution could be controlled whether separated or integrated. However, published, defined interfaces seem [to me, and IANAL] to be functional rather than expressive, which would suggest they would be available to anyone to use, whether marked as GPL or not, without making the user a derivative work. Remember that the license controls distribution, not use.

Of course, manufacturers (at least, big, well-established manufacturers) tend to have legal staff who are very conservative; the development rule in using OSS components tends to be "don't be a test case - stay well away from the areas of legal uncertainty."

Bundling and the GPL

Posted Jun 20, 2006 22:02 UTC (Tue) by khim (subscriber, #9252) [Link]

The more interesting question, today, is "what is a derivative work." If using interfaces made something a derivative work, then its distribution could be controlled whether separated or integrated.

It's interesting question, yes, but not as much you'd like to think. If you are using published interfaces and don't include verbatim code (usually it's not the case with binary kernel modules because they are including a lot of inline code straight from kernel headers - but there are enouhg projects to make it possible; all unsuccessfull so far). But in reality this question is kind of moot: it does not matter if you are using interfaces or not. If you are bundling two things in one box - they become parts of "collective work".

I think you want to clear totally different distinction: what is "collective work" and what is "mere aggregation". And this is tough question because copyright law does not know about "mere aggregation". Derivative work ? Ok. Can distinguish. Collective work ? Even easier. Mere aggregation... Hmm... what is it ?

And since this "mere aggregation" clause allowance is the only thing makers of all kind of embedded devices are using (no, it's not practical to make your phone to download binary module from ftp)... - this is good question to clarify. Unfortunatelly any definitive answer will anger a lot of people - but at least we'll have clarity.

Bundling and the GPL

Posted Jun 21, 2006 3:30 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

but copyright law doesn't apply to collections, only to derivitive works, so the _first_ question to ask is if it's a derivitive work, if it isn't you don't need to look any further, if it is a derivitive then you look at the license and see what you are allowed to do with it.

the rest of it is an attempt to clarify things for non-legal types. but a license (or a product) does not get to define what _is_ a derivitive work (it can however state that things that could be a derivitive work should not be considered as such, like the system call excemption in linux for example)

Bundling and the GPL

Posted Jun 21, 2006 17:26 UTC (Wed) by khim (subscriber, #9252) [Link]

But copyright law doesn't apply to collections, only to derivitive works

Huh ? What are you smoking ? What is newspaper or magazine ? Right: it's collective work. There are some specific related to collective works like newspapers - but in general it's perfectly legal for the author to give permissin to use it's work only in some collections, but in other ("I give the permission to print my article in any newspaper if this newpasper is not publishing articles by person-I-totally-despise" is Ok).

If you want to talk about copyright - then try to understand at least something about it. If you want to publish collection of works (newspaper, for example) you must obtain permissions from all authors, sorry. GPL does just that: the only collection GPL allows are:

1. Composed only from GPL-compatible software or

2. Composed from GPL-compatible software and unrelated software (mere aggregation clause).

Linking and derived works are totally irrelevant here. What is relevant is "mere aggregation" clause - and it's very unclear clause from legal POV. It's perfectly clear that user-space programs which are using only POSIX API are in clear (Linus said so many times and there are even clarification in kernel's COPYING file), but what about programs who are poking around /proc or /sys ? What about kernel modules ? There are huge gray area... but that grey area is in no way related to "derived work - or not" question. "Derived work" question arises when you are distributing some proprietary program which uses readline library - but readline library is not included. If readline library is included then question about if it's derived work or not will not be even raised: it's collective work and as such it must comply with GPL as whole. The same is true for anything which is not "using kernel services by normal system calls" - i.e. kernel module. The only way to do it in this case is to demonstrate that it's "mere aggregation"... and it's kinda hard to do if we are talking about kernel module...

Bundling and the GPL

Posted Jun 21, 2006 6:15 UTC (Wed) by wilck (subscriber, #29844) [Link]

> it does not matter if you are using interfaces or not. If you are bundling
> two things in one box - they become parts of "collective work".

That's the lawyers' perspective, yes. Because it is much, much easier to talk about bundling than about highly technical questions like whether or not a certain function call is part of a published interface.

To me, as a technical person, the question whether or not e.g. the kernel and a binary driver are delivered in the same CD set seems superficial. That was the point I was trying to make.

If a download script is in a CD set instead of a piece of software, the question would be "Is it the intention of the distributor that (some) users run this script to form an end product which is the combination of GPLd and proprietary components?" and if the answer was yes, the whole thing would have to be considered a derivative work.

Next step: instead of the installation script, the distributor just includes a help page with a link to the downloadable component plus installation instructions. What now?

I don't think the discussion about "mere aggregation" helps a lot either - for any device that can connect to the net in some way, a download URL is just as good as a piece of software on a CD. Most phones can download stuff from the net without trouble. I think the two must be basically regarded equivalent, at least when we talk about the not-too-far future.

Bundling and the GPL

Posted Jun 21, 2006 17:50 UTC (Wed) by khim (subscriber, #9252) [Link]

> it does not matter if you are using interfaces or not. If you are bundling two things in one box - they become parts of "collective work".

Exactly! And when you are talking about law then usual engeenering approach ("let's tackle hard problems first - then simple ones will be resolved automagically") should take a backseat. It's much safer to close simple loopholes - and then you can go further and try close more subtle ones.

Please, please, please at least try to think like "Joe Average" for once. Suppose we are starting from bundling and go from there: first we establish that you can not ship invasive binary modules in the same package as kernel, then we are starting to talk about download scripts and "helpfull instructions", etc. At every stage we are moving from established case where GPL-violation is proven to unknown one. If we'll start from nVidia binary driver (binary blob and open-sourced glue code distributed separately from kernel) and court decides that "it's not GPL violation at all" (quite likely) then you are moving from established case where GPL in not violated to unknown one.

You can be absolutely sure that first approach will give GPL more reach in the end. Because if first approach it looks like GPL-violators are trying one trick after another to circumvent GPL and in second approach it looks like "GPL-zealots" are attacking people in smaller and smaller area.

Is it really so hard to understand ? I'm not saying that we should forget about "derived work" question - I just think it's silly to start with this quite complex question where there are hundreds of less-subtle violators around.

Bundling and the GPL

Posted Jun 22, 2006 4:23 UTC (Thu) by xoddam (subscriber, #2322) [Link]

Great point. Cover all the firm ground before trying to claim the
mire :-)

Bundling and the GPL

Posted Jun 22, 2006 8:04 UTC (Thu) by wilck (subscriber, #29844) [Link]

Makes sense, from a strategic viewpoint. But what is the goal of that strategy?

Will the end result be that bundled packages are "wrong" while download scripts are "right" (as many now seem to anticipate)? I, for one, consider that worst of both worlds - binary modules would still exist, while the hassle of downloading and integrating them would be on the user's side.
Is that really what we want?

Talking about generic Linux distributions here.

It's different if someone bundles e.g. the kernel and nVidia module _with corresponding hardware_ to form a special product with preinstalled Linux. that would be a pretty obvious violation, because it is bundling _with a specific purpose_: a new "value-added" product.

IAobviouslyNAL, these are just my gut feelings.

Bundling and the GPL

Posted Jun 23, 2006 22:06 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Khim wrote:

I'm not saying that we should forget about "derived work" question - I just think it's silly to start with this quite complex question where there are hundreds of less-subtle violators around.

You seem to have forgotten the topic of this thread, which you started. It isn't where is the reasonable place to start in advancing or understanding GPL. It's what is the more interesting GPL-related legal question.

Khim wrote:

The most interesting case is not binary modules per se but combination of binary module and kernel!

And then sepreece wrote, in contradiction:

The more interesting question, today, is "what is a derivative work."

I agree with sepreece. The derivative work question is more interesting than the collective work one. If an author can stop you from independently distributing your entirely original code because it gets used with the author's code, that's worth a headline. If a certain way of shipping a bundle of software is found to be creating an indivisible new whole -- that's kind of a yawner.

Also, in terms of impact on the world -- a derivative work finding is pretty hard for a distributor to work around. A collective work finding just means the distributor has to bundle somewhat more loosely.

Bundling and the GPL

Posted Jun 21, 2006 12:58 UTC (Wed) by sepreece (subscriber, #19270) [Link]

It absolutely IS practical for a mobile phone to download software when it is first activated. In fact, most phones already do so, either in the shop or later, and most modern phones are also capable of downloading software updates after ship, either automatically or on request. This is used to repair problems or add services.

Bundling and the GPL

Posted Jun 21, 2006 17:33 UTC (Wed) by khim (subscriber, #9252) [Link]

In fact, most phones already do so, either in the shop or later

Irrelevant. In most cases it's not done by end-user so it just shifts the problem around: now Motorolla or Samsung are not "pirats" themselfs but are "helping piracy" - and we know how well our lawmakers and lawers like firms who are "helping piracy" (like Napster, for example) ?

The fact of the matter: if we can astablish that it's NOT OK to distribute linux kernel and binary module as one bundle everything else (download scripts, helpfull instructions, etc) will be viewed from this perspective.

Bundling and the GPL

Posted Jun 21, 2006 19:27 UTC (Wed) by sepreece (subscriber, #19270) [Link]

Sorry, I must not have made myself sufficiently clear. You said it was not practical for a phone to download additional software after delivery to the customer. I said, it's completely practical and most phones already do so. You opened a particular question, I simply closed it.

I think a manufacturer would have a reasonable claim that this was not, in any meaningful sense, distribution "with" or "as a whole" with the software that was actually distributed in the device, especially if adding it was part of adding an optional service to the phone (even if the added service was as central as "voice communications").

The whole anti-TiVoization article is based on the assumption that an embedded device is, essentially no different from a general-purpose computer on which a user may load any software she likes. If you accept that argument, then you have to accept the argument that a phone, shipped with a purely GPL Linux kernel is also a general-purpose computer and it is not central to its existence that additional telephony software be added to it. If the device does SOMETHING without the additions, that makes it independent of any subsequent optional additions.

So, the more interesting question remains the interpretation of "derivative work", because that would govern distribution of software created by a manufacturer to work with GPLed software - what interfaces is is safe to use, what modes of interaction with the device are acceptably decoupled or functional versus "expressive."

DISCLAIMERS: Note that, at least in the phone space, the manufacturers generally want to play by the rules and not work around them! They have lawyers who generally advise them not to get anywhere near ambiguous license issues. They also generally want to enable an ecosystem of add-on software developers, as soon as the regulatory issues can be worked out. I can, as an individual, express opinions about how I think the GPL should be interpreted, but in doing so IANAL and certainly do NOT speak for my employer, who is a device manufacturer.

Bundling and the GPL

Posted Jun 20, 2006 22:07 UTC (Tue) by khim (subscriber, #9252) [Link]

You'd be surprised. For a lot of hardware makers it's tough choice to do. "Normal users" like to have everrything working "out of the box". They will not connect new phone, PDA or DVD player just to make it functional.

Distributors are not the evildoers. Hardware makers are: instead of providing enough documentation to make truly free drivers possible they are playing games. And this is what we should try to stop.

Bundling and the GPL

Posted Jun 21, 2006 19:31 UTC (Wed) by sepreece (subscriber, #19270) [Link]

Note that for connected devices (like cell phones and TiVo-like DVRs), it is completely invisible to the user whether the device is complete "out-of-the-box" or downloads additional software. The needed transactions can happen as soon as the device is connected and the device is without its connected functions until it's connected, anyway.