License? [LWN.net]

License?

Posted Nov 30, 2010 21:09 UTC (Tue) by madscientist (subscriber, #16861)
In reply to: License? by kripkenstein
Parent article: The kernel and the C library as a single project

I don't think this is an issue. The only thing that matters from a licensing perspective is whether the libc is legally a derived work of the kernel (or vice versa). If they are not currently derived works being distributed on separate sites, then I don't see how changing them to be distributed on the same site causes them to become derived works. The interface between the kernel and libc will continue to be the syscall interface + header files, just as today.

Of course we cannot have a libc which is licensed under the GPL. It must be the LGPL, or else something weaker. Otherwise no one will ever use it.

to post comments

License?

Posted Nov 30, 2010 22:11 UTC (Tue) by gmaxwell (guest, #30048) [Link] (30 responses)

"The only thing that matters from a licensing perspective is whether the libc is legally a derived work of the kernel (or vice versa)"

Your message appears to embody a commonly repeated piece of misinformation about how copyleft licenses work. I'm responding in order to squelch its continued dissemination, not because I disagree with your conclusion.

"Is foo a legally a derived work of Bar" is almost never a important question with respect to license compliance of bundled software.

The relevant software license sets out conditions under which is can be lawfully reproduced. Absent the license you can not lawfully reproduce the software. A license for Bar might specify that you can only reproduce the software on a computer that doesn't contain a copy of nethack and the requirement would be perfectly enforceable. Not become nethack is somehow a derivative of Bar and is thus tainted by bar's license but simply because the license of bar says so, and you're distributing bar so you must abide by the license or infringe. If you don't like it then you can opt not to distribute Bar by doing so escape its requirements.

The legal criteria for how copyright encumbrances flow from place to place are relevant in some contexts, but usually not in the context of bundling because no 'flowing' is required: When you bundle you must obey _ALL_ relevant licenses.

The GPLv3 carefully avoids any mention of the word "derivative" in order to avoid this confusion with other uses of the heavily overloaded term.

So in the case kernel and libc you have to actually look at what the licenses require. You can't just depend on some extenal notion of a legal definition of a derived work to somehow bound things, because it wouldn't. Considering that the distributions bundle these things already I think it's safe to say that there currently isn't a problem. It may more complicated as each of the packages is intimately extended with code existing in the other.

Yup. You just omitted important fact.

Posted Nov 30, 2010 22:47 UTC (Tue) by khim (subscriber, #9252) [Link] (22 responses)

The legal criteria for how copyright encumbrances flow from place to place are relevant in some contexts, but usually not in the context of bundling because no 'flowing' is required: When you bundle you must obey _ALL_ relevant licenses.

Yup. This is correct. But it's important to continue you explanation: the words cited above would imply that even today you can not actually distribute kernel and non-GPLed programs... yet people do it with impurity. Why it's not a problem today? This is important stuff.

Considering that the distributions bundle these things already I think it's safe to say that there currently isn't a problem.

Yup, but again: why? It's important.

It may more complicated as each of the packages is intimately extended with code existing in the other.

Not "more compilcated". Impossible. The reason why you can distribute kernel with GLibC, newlib or Android's bionic is simple: "mere aggregation" clause. All version of GPL include this "escape clause": if you are distributing GPLed product and non-GPLed product on the same CD or on the same NAND chip it's Ok as long and GPLed product and non-GPLed product are developed separately and not tied to each other. Today it's easy: Linux kernel exposes simple, documented interface, there are multiple independent implementations of it on both consumer and producer side (on the consumer side there are GLibC, uClibc, klibc, etc - and on producer side there are at least Linux kernel and emulation of said kernel in FreeBSD). It's additionally reinforced by explicit promose in kernel's COPYING file (NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls). So everything is great. But if libc will be developed in tandem with kernel... the "mere aggreggation" defense evaporates and "user programs that use kernel services by normal system calls" defense evaporates too! At this point there are no separation line which will allow you to redistribute non-GPLed programs!

No, the full libc distributed with kernel idea will not fly - and AFAICS this is not what is discussed at all.

Yup. You just omitted important fact.

Posted Nov 30, 2010 23:12 UTC (Tue) by madscientist (subscriber, #16861) [Link] (21 responses)

> But if libc will be developed in tandem with kernel... the "mere
> aggreggation" defense evaporates

I don't believe you're correct here.

First, the "mere aggregation" clause is not a "get out of jail free" card, where any cross-derivation of two different pieces of software magically becomes just fine if they're aggregated together on a single CD. If two works are legally derived, then you have to deal with the GPL, REGARDLESS of whether they're aggregated or not. The "mere aggregation" clause just makes crystal clear something that is probably already true anyway: that bundling two completely unconnected things together on a single media does not magically make them legally derived from each other.

Second, the reason glibc, etc. and the kernel are allowed to use different licenses is not the "merge aggregation" clause. These are not considered to be derived works of the kernel and so they don't have to take the kernel's license into account.

So whether libc is developed by the kernel developers or by GNU, and how they are bundled (or not) together, is not relevant in terms of licensing. All that matters is derivation (without derivation there is no way to enforce) and the content of the license.

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 1:01 UTC (Wed) by khim (subscriber, #9252) [Link] (20 responses)

The "mere aggregation" clause just makes crystal clear something that is probably already true anyway: that bundling two completely unconnected things together on a single media does not magically make them legally derived from each other.

To bind two completely unconnected things together on a single media you still need explicit permissions from both copyright owners. And if one hates the guts of other... well, that's it: you can not distribute these two things on the same media. People from Be, Inc tested your insane theory - and failed (with dire consequences). Copyright owners can and often do forbid to distribute things together under same cover.

People are often surprised to hear that, but think about it: can you put Linux kernel and Adobe Flash player on the same media? No! But why "no"? Because standard Adobe Flash license forbids that. You can buy separate redistribution license - but this is different story (and said redistribution license often does impose limitations over what can you put on the same CD). If Adobe's license can allow you to run and use program but will stop the redistribution then why GPL can not do the same? It can and it does - unless you'll use GPL for the whole "work" you plan to redistribute or use "mere aggregation" escape.

Second, the reason glibc, etc. and the kernel are allowed to use different licenses is not the "merge aggregation" clause.

Ok, I'll bite. What other clause gives you this right? GPL extends to "any work based on the Program" - and of course compilation of kernel and some other library/program is "any work based on the Program". If you'll forget about "mere aggregation" clause, that is.

These are not considered to be derived works of the kernel and so they don't have to take the kernel's license into account.

If they are distributed separately? Sure. When they are combined to form bigger, larger, work like Android or Ubuntu? No. It's like when Alice hates Bob's guts (they had messy divorce or something): if you are lucky you can get a permission to publish a book of stories from two under some cover - buf if they'll demand to never put two such stories on one page... you must obey. Or not publish said book at all.

All that matters is derivation (without derivation there is no way to enforce) and the content of the license.

Right. So we need to check if Android or Ubuntu are derived work of kernel and if the license of kernel cover the whole "work". First part is simple: of course Android and Ubuntu are derived works! They quite literally include millions of bytes of code from kernel! Second part is equally clear (if you ignore "mere aggregation" clause): you can only ever redistribute "any work based on the Program" if you'll distribute the whole compilation under GPL terms.

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 1:23 UTC (Wed) by sfeam (subscriber, #2841) [Link] (9 responses)

you can not distribute these two things on the same media. People from Be, Inc tested your insane theory - and failed (with dire consequences).

I may be misremembering, but the article you link to reinforces my recollection that BeOS ran up against the bulk licensing agreements between Microsoft and OEMs, which forbade to sell dual-boot machines. However unfortunate that may have been, it doesn't directly bear on the question of bundling linux software on distribution media.

Oh, but it does...

Posted Dec 1, 2010 3:36 UTC (Wed) by khim (subscriber, #9252) [Link] (8 responses)

I may be misremembering, but the article you link to reinforces my recollection that BeOS ran up against the bulk licensing agreements between Microsoft and OEMs, which forbade to sell dual-boot machines.

Yup.

However unfortunate that may have been, it doesn't directly bear on the question of bundling linux software on distribution media.

How come? Microsoft's Windows license given for OEMs made it illegal to distribute totally unrelated piece of code on the same medium unless it was licensed in some quite specific way - the same as with Linux kernel and linux programs. In case of Windows license only allows programs written for Windows but not separate OSes, in case of Linux license allows not only Linux programs but also any "mere aggregation" software. If Microsoft's license can stop BeOS inclusion then Linux license can stop any other software inclusion.

You can only redistribute proprietary programs (and FOSS programs with GPL-incompatible licenses) with Linux because GPL gave you explicit permission. Copyright alone does not give you such rights.

Oh, but it does...

Posted Dec 1, 2010 4:22 UTC (Wed) by sfeam (subscriber, #2841) [Link] (7 responses)

Microsoft's Windows license given for OEMs made it illegal to distribute totally unrelated piece of code on the same medium unless it was licensed in some quite specific way

That's not what it says in the article you linked to. As I understand it, the OEM's were allowed to ship BeOS in addition to Windows (or at any rate they thought they were and continued to do so). But in order to get the bulk pricing on Windows they could not enable dual boot - they instead resorted to offering instructions on how to switch your disk to booting BeOS (only) rather than Windows (only). So from that description, the limitation was not "the copyright or license forbids joint distribution"; it was "we will charge you more if you do so". And even so it wasn't a direct restriction on distribution, only on the machine configuration. So again, I really don't think the BeOS story is a close enough parallel to be relevant.

Anyhow, back to your earlier diagnosis that if some clib equivalent were distributed with the kernel there would no longer be a dividing line across which the license terms did not apply. That makes no sense to me. The line would be drawn at the API between clib and user programs. Not much difference to what we have now.

Oh, but it does...

Posted Dec 1, 2010 11:54 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (6 responses)

And Microsoft's position here even makes sense, even if it was in practice anti-competitive and therefore perhaps unacceptable.

Microsoft believes (correctly) that most of its users don't understand much about computers. If you ask them "Which OS are you booting?" the _better_ answers will be something like "Microsoft" or "Office" and most people will just stare uncomprehending.

OEMs have consistently choked systems with shovelware because doing so is profitable and the margins in the PC world are beyond razor thin. So Microsoft's OEM license includes limits on shovelware, one of them ensured that when you buy a Windows PC, it boots Windows.

Because the alternative is it boots "AdBrowse - the great new way to earn valuable prizes while using the Internet" for which the OEM was paid $$$. And only a tiny fraction of users know to hold down Shift F8, pick "Windows" from the menu and boot the actual OS instead. Everybody else just complains that now "the Microsoft" makes them watch adverts, just as they queued up to complain that "the Facebook" had changed when they typed "facebook login" into a browser and got some blog page not facebook.com

More recently we've seen what happens when Microsoft's OEM negotiators let the OEMs bully them - that's what led to the Vista debacle. Every top-selling PC in Vista's opening season was unsuitable to run Vista, but OEMs didn't want these PCs gathering dust as "XP only" so they moaned until Microsoft authorised Vista badges of some kind for these machines.

Oh, but it does...

Posted Dec 2, 2010 0:57 UTC (Thu) by cmccabe (guest, #60281) [Link] (5 responses)

> And Microsoft's position here even makes sense, even if it was in practice
> anti-competitive and therefore perhaps unacceptable.

OEMs continue to choke systems with shovelware. Microsoft doesn't give a hoot as long as they get their cut. In fact, Microsoft has made the situation considerably worse by refusing to give out Windows install discs along with new computers. It used to be that you could at least re-install a clean version of Windows to get rid of the adware and spyware. Now, all they give you is essentially a restore-from-ISO tool that has all the crap on it.

The restriction on dual-boot computers was never about helping users; it was always about killing the competition. Enforcing trademark law would have been enough to ensure that users didn't blame Windows for Linux's (or BeOS's) failings.

> More recently we've seen what happens when Microsoft's OEM negotiators let
> the OEMs bully them - that's what led to the Vista debacle

Bad project management led to the Vista debacle. If your new operating system can't run on the newest hardware that's coming off the production lines, maybe you ought to delay shipping it until it can.

Don't get me wrong-- there's a lot of things that Microsoft has done well (Xbox comes to mind). But Vista wasn't one of them.

Oh, but it does...

Posted Dec 2, 2010 1:51 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (4 responses)

The restore situation I can explain (the quality of the restore though, you should blame on your OEM).

Despite everybody's best efforts, none of today's PC operating systems actually work properly on a brand new PC. In say, Fedora this can be painfully obvious as your brand new HP laptop runs X with VESA graphics or refuses to acknowledge the existence of its built-in touchpad. Sure there'll be an update that fixes it, but that's later, and you've got the new laptop now.

In Windows this is hidden by pre-installing the necessary patches, new drivers, utilities etc. at the factory.

But if the user re-installs from a "clean" OS DVD they don't get any of that, and then end up with the experience familiar to bleeding edge Linux people. They will, of course, report this as a fault, which will cost someone a bunch of support money. Hence, there is no way to install a clean OS, because they know it won't work properly anyway.

You mention trademark law as a solution to the dual boot problem. This is charmingly naive - to sophisticates like us it's obvious if you're running OS/2 or Mac OS X, but to the average user it's all a muddle. My sister continues to be caught out by the need to buy different software for her "new computer" (a MacBook). Trademarks don't help because they're not aware of the trademarks, it's just more technical mumbo-jumbo.

Oh, but it does...

Posted Dec 2, 2010 3:42 UTC (Thu) by cmccabe (guest, #60281) [Link] (3 responses)

> Despite everybody's best efforts, none of today's PC operating systems
> actually work properly on a brand new PC. In say, Fedora this can be
> painfully obvious as your brand new HP laptop runs X with VESA graphics or
> refuses to acknowledge the existence of its built-in touchpad. Sure
> there'll be an update that fixes it, but that's later, and you've got the
> new laptop now.

It's fine to offer a restore CD with the driver pre-loaded. However, Microsoft should also offer the ability to download a clean version of Windows from its website, if you input the correct product key.

Microsoft has spent a lot of effort tying product keys to specific configurations and models of computer. They created Windows Genuine Advantage and barred pirated copies of the OS from downloading most updates. Offering a copy of the original Windows CD would really not be challenging for them.

> You mention trademark law as a solution to the dual boot problem. This is
> charmingly naive - to sophisticates like us it's obvious if you're running
> OS/2 or Mac OS X, but to the average user it's all a muddle. My sister
> continues to be caught out by the need to buy different software for her
> "new computer" (a MacBook). Trademarks don't help because they're not
> aware of the trademarks, it's just more technical mumbo-jumbo.

It's not "charmingly naive" to believe that users know the difference between a can that says "Coke" and one that says "Pepsi". It's also not naive to believe that users can't tell the difference between a big Apple logo plastered on the startup screen, and on the desktop afterwards, and the same situation with a Windows logo.

Frankly, I find your comments to be elitist. Just because a person is not a computer professional, doesn't make him stupid. There is a difference between being stupid and choosing not to invest time and energy in something.

Oh, but it does...

Posted Dec 2, 2010 12:08 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (2 responses)

It's not "charmingly naive" to believe that users know the difference between a can that says "Coke" and one that says "Pepsi".

And if that was the comparison we were actually discussing it might be relevant.

There is a difference between being stupid and choosing not to invest time and energy in something.

Indeed, and a great many computer users (which means many millions of Microsoft customers) choose not to invest time and energy into understanding how a computer works. Microsoft has no problem with this, but it does mean they need to ensure that when those users buy a "PC with Windows" they don't get "a PC that could run Windows, but right now it's booted into BeOS". Because Microsoft (not Be Inc, not the guy on Slashdot promoting BeOS) ends up with a lot of the support costs if that happens.

If it's "elitist" to believe that some people don't care about computers then I guess I'm an "elitist" by your definition, but I caution you that this is an unusual definition which is likely to cause you problems.

Oh, but it does...

Posted Dec 19, 2010 11:37 UTC (Sun) by Jan_Zerebecki (guest, #70319) [Link] (1 responses)

AFAIK Microsoft does not offer free support with normal OEM versions, I would guess they make money with all their support offers, that need work per support incident, i.e. not including things like Documentation. (I just looked it up that a support Question for Microsoft Windows 7 Professional N costs 72.)

Oh, but it does...

Posted Dec 19, 2010 16:22 UTC (Sun) by Trelane (guest, #56877) [Link]

Absolutely right. There are a large number of people in violation of the OEM licensing terms. Read the FAQ for yourself: Some highlights:

Q. My customer wants to purchase a "naked" PC from me and acquire the Windows license through a Volume Licensing agreement. Is this OK? A. No. Full Windows licenses are not available through any Microsoft Volume Licensing program, including academic volume licenses. The customer must first acquire a Windows operating system license via OEM software included with a new PC from an OEM or system builder, or via the retail channel.

Q. Can my customers transfer or sell their OEM software licenses? A. After an OEM software license has been installed on a PC, the license may not be installed on or transferred to another PC. However, the entire PC may be transferred to another end user along with the software license rights. When transferring the PC to the new end user, the software media, manuals (if applicable), and Certificate of Authenticity label must be included. It is also advisable to include the original purchase invoice or receipt. The original end user cannot keep any copies of the software.

Q. Can two or more users access and fully utilize OEM Windows operating systems concurrently on the same machine? A. No. The End User Software License Terms do not permit two or more users to concurrently use the full feature sets of Windows operating systems. However, the Windows End User Software License Terms do allow for a limited number of computers or other electronic devices to connect to the computer upon which the software is installed to utilize one or more of the following services: File Services, Print Services, Internet Information Services, and telephony services. The End User Software License Terms also permit limited concurrent use in connection with the Remote Assistance and NetMeeting technologies. Please refer to the applicable End User Software License Terms for detailed information regarding such limited concurrent uses.

Q. How does a company qualify to become a direct Microsoft OEM? It seems that the larger companies currently have an unfair advantage compared with smaller OEMs. A. Direct OEM licensees do receive a discount compared to buying through the System Builder channel, but that discount is based on the licensees commitment to receive ongoing bulk shipments versus purchasing at will. Other elements of the direct licensing agreement require significant initial investment from the OEM. Furthermore, legal and technical requirements are placed on direct OEMs to protect Microsoft intellectual property, and these requirements can add other costs to the production of a PC. The primary difference between the two programs cannot be gauged merely by looking at prices and software licenses. Each program is designed to meet the specific needs of the partner.

Q. Can a PC with an OEM Windows operating system have its motherboard upgraded and keep the same license? What if it was replaced because it was defective? A. Generally, an end user can upgrade or replace all of the hardware components on a computerexcept the motherboardand still retain the license for the original Microsoft OEM operating system software. If the motherboard is upgraded or replaced for reasons other than a defect, then a new computer has been created. Microsoft OEM operating system software cannot be transferred to the new computer, and the license of new operating system software is required. If the motherboard is replaced because it is defective, you do not need to acquire a new operating system license for the PC as long as the replacement motherboard is the same make/model or the same manufacturer's replacement/equivalent, as defined by the manufacturer's warranty. The reason for this licensing rule primarily relates to the End User Software License Terms and the support of the software covered by that End User Software License Terms. The End User Software License Terms is a set of usage rights granted to the end user by the PC manufacturer and relates only to rights for that software as installed on that particular PC. The system builder is required to support the software on the original PC. Understanding that end users, over time, upgrade their PCs with different components, Microsoft needed to have one base component "left standing" that would still define the original PC. Since the motherboard contains the CPU and is the "heart and soul" of the PC, when the motherboard is replaced (for reasons other than defect) a new PC is essentially created. The original system builder did not manufacture this new PC, and therefore cannot be expected to support it.

Q. Can I create my own recovery disks and sell these with the computer systems that I build? I have heard that direct OEMs can do this, so why can't I? A. No. System builders may not offer a recovery solution with removable media (e.g., a recovery CD) because it is prohibited by the terms of the Microsoft OEM System Builder License. A full version of the Windows operating system is provided on a hologram CD in the Microsoft System Builder pack for each end user, and the CD must be transferred to the end user at the time of distribution. The hologram CD acts as the recovery media. However, system builders can offer a hard disk recovery solution in addition to, but not as a replacement for, the hologram CD. Third-party software companies can also help system builders do this. Learn more about the legal, licensing, and technical requirements for this type of hard disk-based recovery solution. System builders are bound by the Microsoft OEM System Builder License, affixed to the side of the System Builder packs, which is different than the direct agreements utilized by direct OEMs. The licensing terms for system builders and large OEMs are different because they are designed to address the specific needs of each community. The right to create recovery media is limited to the OEMs with direct agreements; however, these OEMs are also bound by other contractual obligations. The OEM System Builder License is designed to make it easy for system builders to acquire and distribute genuine Microsoft software, and accordingly, its terms are different.

Q. Can I provide a computer system to my customer without an operating system (also referred to as a "naked PC")? A. Yes. There is nothing illegal about selling a computer system without an operating system. However, getting the operating system preinstalled is your customer's most cost-effective way to acquire a genuine Windows operating system license. A customer who subsequently wants to install a Microsoft Windows desktop operating system on that naked PC will need to acquire it through the retail (full packaged product) channel which is a more costly option. Full Windows operating systems are not available through any Microsoft Volume Licensing program, and an OEM operating system license cannot be transferred from an "old" PC to a new one.

Q. What are the different ways in which Microsoft OEM System Builder Windows desktop operating system licenses can be distributed? A. The current OEM System Builder License allows system builders to distribute Windows desktop operating system licenses in the following ways: 1. Preinstalled on a new PC. 2. Unopened OEM System Builder packs (1-, 3-, or 30-packs) can be distributed to other system builders by themselves. Note that they must remain unopened so the receiving system builder can accept and be bound by the break-the-seal license agreement that is affixed to the pack.

Additional information "For hobbyists":

OEM System Builder Software[...]Must be preinstalled on a PC and sold to another unrelated party.

(commonly misunderstood part bolded and partially italicized by me)

OEM System Builder Software[...]System builder that preinstalled the software must provide support for the software.

Q. I would like to build PCs for my company and use OEM System Builder software for the operating system. Can I do this? A. OEM System Builder software must be preinstalled and then resold to another party. If you are using the PC within your organization, this "resale" requirement will not be met. In addition, as a system builder preinstalling OEM System Builder software onto new PCs, this requires that you grant the end user license terms to the third party acquiring the PCs from you. If you are distributing the PCs within your organization, you cant grant the end user license terms to yourself.

Volume licensing FAQ is also highly recommended: http://www.microsoft.com/licensing/resources/faq.mspx

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 2:51 UTC (Wed) by madscientist (subscriber, #16861) [Link] (5 responses)

> To bind two completely unconnected things together on a single media you
> still need explicit permissions from both copyright owners.

Of course, to redistribute something you need permission because copyright restricts redistribution. And of course a license that grants you permission to redistribute one way MAY restrict redistribution in other ways: this is not uncommon even. As you point out, many licenses such as Adobe's allow you to use the software only if you obtain it directly from Adobe; you cannot give the software to someone else. THAT is why you cannot get a CD with both Linux and Flash bundled on it; it has NOTHING to do with the GPL. You can't distribute a CD that contains nothing but Flash, even... unless you've executed a different license agreement with Adobe.

I guess we can disagree about whether the "mere aggregation" clause is necessary; my belief is that it's there merely as a clarification and that even without it the GPL implicitly allows aggregation. Maybe not. Either way it's moot because the clause DOES exist and so both the GPL and LGPL make explicit that aggregation is allowed.

Your argument was that because the kernel and libc would be developed together, somehow they would not be able to take advantage of the "mere aggregation" clause any longer. In order for that to be the case, libc would have to become a "work based on the Program" (e.g., the kernel); as long as it's not a work based on the Program, it can still take advantage of "mere aggregation". Whether or not libc is a "work based on the Program" depends on whether it is a legally derived work or not; it has nothing to do with the development model.

In other words, as I mentioned before, if libc developed by GNU is not considered to be a derived work of the kernel (and hence can take advantage of "mere aggregation"), then why would libc developed by kernel developers be a derived work (and hence NOT be able to take advantage of "mere aggregation")?

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 3:08 UTC (Wed) by Trelane (guest, #56877) [Link] (4 responses)

Of course, to redistribute something you need permission because copyright restricts redistribution.

No, copyright restricts, erm, copying. Hence the name.

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 3:14 UTC (Wed) by Trelane (guest, #56877) [Link] (2 responses)

Ha. And, of course, I'm wrong. Quoth the Copyright Office (http://www.copyright.gov/circs/circ1.pdf)

Section 106 of the 1976 Copyright Act generally gives the owner of copyright the exclusive right to do and to authorize others to do the following:

To reproduce the work in copies or phonorecords;
To prepare derivative works based upon the work;
To distribute copies or phonorecords of the work to the public by sale or other transfer of ownership, or by rental, lease, or lending;
To perform the work publicly, in the case of literary, musical, dramatic, and choreographic works, pantomimes, and motion pictures and other audiovisual works;
To display the work publicly, in the case of literary, musical, dramatic, and choreographic works, pantomimes, and pictorial, graphic, or sculptural works, including the individual images of a motion picture or other audiovisual work; and
In the case of sound recordings,* to perform the work publicly by means of a digital audio transmission.
In addition, certain authors of works of visual art have the rights of attribution and integrity as described in section 106A of the 1976 Copyright Act.

"Mere aggregation" is there for a reason.

Posted Dec 2, 2010 1:49 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

That's true of section 106 the original Copyright Act, but section 109 ("Limitations on exclusive rights") and the Doctrine of First Sale pretty much nullify the third point in the case of simple redistribution or public exhibition of existing copies--apart from sound recordings or software, which were (idiotically) excluded from the limitations in section 109(a) by 109(b).

Copy, right?

Posted Dec 6, 2010 0:24 UTC (Mon) by marcH (subscriber, #57642) [Link]

> Ha. And, of course, I'm wrong.

Err... you mean, you are right?

Every bullet point you quote is about reproducing the original work in one way or the other. That does not seem to stretch the meaning of "copy" a lot, or does it?

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 10:07 UTC (Wed) by PO8 (guest, #41661) [Link]

The term "copyright" originally was used to describe rights upon "copy" in the older sense of written material. The term itself had nothing explicit to do with "copying". Of course, it's easy to see where the confusion could come from here.

"Mere aggregation" is there for a reason.

Posted Dec 1, 2010 14:01 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> > These are not considered to be derived works of the kernel and so they don't have to take the kernel's license into account.

> If they are distributed separately? Sure. When they are combined to form bigger, larger, work like Android or Ubuntu? No.

You are right but *in the case of the GPL* it does not make much difference since the GPL does not care about mere aggregation.

> It's like when Alice hates Bob's guts (they had messy divorce or something)

The GPL is all love!

> First part is simple: of course Android and Ubuntu are derived works! They quite literally include millions of bytes of code from kernel!

Ubuntu has no licence but a large *collection* of them, so I really doubt such an example will help make anything clearer.

Otherwise nice post, thanks.

"Mere aggregation" is there for a reason.

Posted Dec 2, 2010 18:25 UTC (Thu) by vonbrand (guest, #4458) [Link] (1 responses)

There must be a license (i.e., a permission to do something you normally aren't allowed to do) on the collection as such, else you can't redistribute it either... Red Hat (the collection) used to go under GPL, I suppose Fedora does the same (plus trademark restrictions). Ubuntu does restrict (via trademark) what derivative can (and can't) be called Ubuntu.

"Mere aggregation" is there for a reason.

Posted Dec 2, 2010 18:52 UTC (Thu) by sfeam (subscriber, #2841) [Link]

It is possible to claim copyright on a compilation (== "collection"), yes. But I am not aware of any requirement to do so. If there is no additional license/copyright on the compilation as a whole, then redistribution is only limited by the terms of the individual items within the collection.

In fact you can only claim additional copyright on the collection if your preparation of the compiled materials involves sufficient additional work to constitute "an original work of authorship" in its own right. Just stuffing a bunch of existing packages on a disk would be unlikely to merit a new copyright as a compilation. Preparing a full linux distro's worth of packages selected and possibly modified for interoperability, together with meta-information, installation scripts, yadda, yadda, is clearly a different story.

"Mere aggregation" is there for a reason.

Posted Dec 2, 2010 1:10 UTC (Thu) by cmccabe (guest, #60281) [Link]

> Right. So we need to check if Android or Ubuntu are derived work of kernel
> and if the license of kernel cover the whole "work". First part is simple:
> of course Android and Ubuntu are derived works! They quite literally
> include millions of bytes of code from kernel! Second part is equally
> clear (if you ignore "mere aggregation" clause): you can only ever
> redistribute "any work based on the Program" if you'll distribute the
> whole compilation under GPL terms.

Android as a whole is, indeed, a derived work of the Linux kernel. But that doesn't mean that all of the component parts of Android are derived works of the Linux kernel. You can, and companies do, make changes to the BSD part of Android and ship them, without making the code publicly available.

Here is another example. If you're a book seller, you can put several books on the shelf-- even ones with the same subject-- that have different copyrights. You do not need to get permission from the authors to do so. Just putting two things side by side does not make one a derived work of the other.

And we haven't even talked about "fair use"-- the quantum physics of copyright law. What a confusing topic!

License?

Posted Nov 30, 2010 22:49 UTC (Tue) by madscientist (subscriber, #16861) [Link]

I should have been more clear and quoted the parent of my message. The statement was "But if the two are worked on as a single project, presumably that means libc would need to be GPL2 as well."

My comment was "The only thing that matters from a licensing perspective is whether the libc is legally a derived work of the kernel (or vice versa)."

I meant this in the context of the parent: the only thing that matters when deciding if libc would have to adopt the same license as the kernel is derived work status. I wasn't talking at all about whether it could be distributed, etc.

License?

Posted Dec 1, 2010 1:10 UTC (Wed) by cmccabe (guest, #60281) [Link] (3 responses)

> Your message appears to embody a commonly repeated piece of misinformation
> about how copyleft licenses work. I'm responding in order to squelch its
> continued dissemination, not because I disagree with your conclusion.
>
> "Is foo a legally a derived work of Bar" is almost never a important
> question with respect to license compliance of bundled software.
>
> The relevant software license sets out conditions under which is can be
> lawfully reproduced. Absent the license you can not lawfully reproduce the
> software. A license for Bar might specify that you can only reproduce the
> software on a computer that doesn't contain a copy of nethack and the
> requirement would be perfectly enforceable. Not become nethack is somehow
> a derivative of Bar and is thus tainted by bar's license but simply
> because the license of bar says so, and you're distributing bar so you
> must abide by the license or infringe. If you don't like it then you can
> opt not to distribute Bar by doing so escape its requirements.

Did you read this part of the GPLv2?

> In addition, mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of
> a storage or distribution medium does not bring the other work under
> the scope of this License.

Since both the kernel and glibc are under the GPLv2 here, your hypothetical considerations about licenses that restrict bundling are irrelevant. The OP is correct.

P.S. Not everything that companies try to throw into EULAs and software licenses is legally binding. I think a judge would probably disagree with you that requiring the user to uninstall an unrelated piece of software to use your software was "perfectly reasonable." Otherwise, Microsoft, IBM, and others would have used this tactic already.

Yes, they do use this tatic.

Posted Dec 1, 2010 4:00 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

I think a judge would probably disagree with you that requiring the user to uninstall an unrelated piece of software to use your software was "perfectly reasonable." Otherwise, Microsoft, IBM, and others would have used this tactic already.

We are not talking about uninstallation. We are talking about bundling. And yes, restrictions here are quite legal and at least Microsoft actually uses this tatic - and judges accept it.

It's the same as with book: if you buy two books from authors which hate each other and then you can use scissors and glue to create "private compilation" of their works - noone can prevent this. But if you want to publish such compilation you'll need permission from both authors.

Not aggregation

Posted Dec 1, 2010 12:09 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Again, the Bootloader restriction doesn't say anything about aggregation.

The rule was, if you want OEM discounts for a Windows license the PC must actually boot Windows, using the Windows bootloader as supplied by Microsoft. Pre-install Linux, OpenBSD, BeOS and OS/2 on them if you like, but they must boot Windows, using the Windows bootloader.

Microsoft also separately asserted that OEMs mustn't sell non-Windows PCs if they want the discount. That's a much more obviously anti-competitive rule, and they've been beaten up for it on several occasions. But again it wasn't about aggregation - in this case the OEMs weren't providing Windows (on those PCs) at all.

Yes, they do use this tatic.

Posted Dec 2, 2010 0:42 UTC (Thu) by cmccabe (guest, #60281) [Link]

> We are not talking about uninstallation. We are talking about bundling.
> And yes, restrictions here are quite legal and at least Microsoft actually
> uses this tatic - and judges accept it.

As far as I know, the legality of those contracts between Microsoft and the OEMs was never tested in court. So you can't say "judges accept it," because they were never asked.

It would be incredibly self-destructive for any OEM to sue Microsoft over this matter, because Microsoft has the ability to make or break them by offering or witholding discounts on Windows. To put it another way, Microsoft is the sole supplier for an essential part-- the Windows license.

> It's the same as with book: if you buy two books from authors which hate
> each other and then you can use scissors and glue to create "private
> compilation" of their works - noone can prevent this. But if you want to
> publish such compilation you'll need permission from both authors.

That's a clear, obvious case of creating a derived work. It has nothing to do with bundling.

On a somewhat related note, I know that Microsoft claims (in their EULA) that you can't run certain versions of Windows inside a virtual machine. I'd really like to see the legality of that restriction tested in court.

If it's legal for them to enforce this restriction, then logically it should be legal for any program to do the same-- so we'd end up with a bunch of programs charging extra for the "prviliege" of using them inside a virtual machine.

License?

Posted Dec 1, 2010 9:07 UTC (Wed) by lethal (guest, #36121) [Link]

The linking clauses don't really apply in the context of a vDSO. The vDSO is mapped in to every process space by the kernel, and can be called by anybody. Processes as such have no direct link map knowledge of the vDSO mapping, and must in turn grovel the auxvt for the entry point (especially as these days the page itself is stashed in a vma in order to randomize its location). One can also interrogate the memory map for the running process through procfs to find the mapping. In any event, restricting use of the vDSO would be akin to restricting visibility of system calls to userspace processes depending on licensing, which we don't really do today either. Where the licensing comes in to play is for libraries that encapsulate the system calls that applications in turn link against. If for example your inotify library contains licensing you don't care for, nothing stops you from constructing your own syscall() call-in that stubs in the bits you care about and never touch the library at all. If someone were to create a library (or extend one, in the case of glibc) to wrap in to the vDSO, then those wrappers within that context would be subjected to the licensing of the library, but the vDSO remains wholly insular.

Obeying licenses

Posted Dec 5, 2010 18:48 UTC (Sun) by giraffedata (guest, #1954) [Link]

When you bundle you must obey _ALL_ relevant licenses.

A license isn't something you obey. It doesn't command you to do anything. Copyright law is something you have to obey.

When you bundle, you must meet the conditions of all relevant licenses (i.e. the licenses you use).

License?

Posted Nov 30, 2010 22:47 UTC (Tue) by marcH (subscriber, #57642) [Link]

> Of course we cannot have a libc which is licensed under the GPL. It must be the LGPL, or else something weaker. Otherwise no one will ever use it.

Damn, this would even prevent anyone from writing any POSIX program at all!

License?

Posted Dec 1, 2010 3:06 UTC (Wed) by vonbrand (guest, #4458) [Link]

This is all nonsense, IMVHO. The author(s) decide which licenses each single source file carries. If a bunch of "libc" files are distributed together with "linux" files, each maintains its own license (just look over the files in the kernel, some are specifically under BSD so they can be shared with other systems). Sure, it can get messy if Alice takes a file written by Bob for "linux" and placed under GPLv2, on which Charlie to Zoe then hacked over the years, and wants to reuse part of it and place it under LGPL as part of "libc". But that doesn't mean BSD/GPLv2/LGPL files can't be distributed in the same tarball, that is mere aggregation.