Posted
by
timothy
on Wednesday August 10, 2005 @06:39PM
from the could-be-could-be dept.

gentoo1337 writes "Eben Moglen of the FSF speaks out in this ZDNet article, noting that GPL v3 may be publicly drafted in early 2006, and in force one year later. The process is very sensitive (noting concerns of forking in the Linux world), but Eben Moglen is optimistic: 'When it's all over, people are going to say, "All that talking for just that much change?" [...] We will do no harm. If we think (some change) may have any unintended consequences, we will not recommend making it.' Controversies aside, there is some good news -- Richard Stallman aims to 'lower barriers that today prevent the mixing of software covered by the GPL and other licenses.' The earlier Slashdot discussion contains complementary info about the intentions of FSF."

Am I the only one who thinks it's going to take longer? Given the number of parties/factions involved (FSF, EFF, RedHat, Linus, ESR, etc.), I think it may take longer. I know that not all those people have to have the new GPL "cleared" with them, but I'm sure they'll all want to weigh in on the process, which will likely lengthen it.

This is such total nonsense. The BSD operating systems get plenty of community contributions. In some cases, BSD-licensed code is more likely to to spur contributions, because it can be used in more scenarios -- companies can use it with no worries about code contamination, for instance, and while they don't have to contribute back to the community, in many cases they will, because it's still in their own best interests.If they contribute their changes back to the main trunk, they'll (probably) be able bene

Except that license-free software is covered by copyright, so there are still legal tendrils. If someone wants to donate software to humanity, I suggest they release it into the public domain, and bugger all the politics.

The reason is that you can't make a copy of that knife and fork and distribute it to others nearly as easily as you can software. The GPL is there to protect the writers from abuse while at the same time encouraging an open community to form around it... If your project is just for fun, and you dont' want any help working on it, go ahead and release it like that... just don't expect anyone to contribute back.

First off, the GPL and any other OSS licences aren't for use, they are for distribution. If you don't distribute you don't have to worry.

Second, you need a licence for other peoples work because without it you have NO legal rights to distribute it. The GPL only gives more than what is stated in law. It should not be mistaken for an EULA which always takes away rights from the user, and mostly are not about distribution but use of the software.

Being that 99 44/100% of all GPL'd software originally came out under the current GPL, will there be any version conflicts with currently licensed software? I.e. if the newer license is *less* restrictive on some point, can existing software licensing be "upgraded" to the new license without have to obtain the acceptance of every single contributor?

So they have an implicit acceptance of whatever might go into to version n years from now?
Like "permission to use the author's power tools on odd weekends"?;-)

This is why I don't quite get the "or later" clause. Sure it adds flexibility, but it basically trusts that the FSF won't do anything you're significantly unhappy with in future versions of the license.

Tying it down to one version, and saying that a later version of the GPL can be applied *provided the original author agrees* might work, but

People should start putting time-limits in their code.. like, this code becomes public domain on such-and-such a date or in addition to the rights granted by the GPL, on {date} the rights of {other less restrictive license} are also granted.

This is necessary because the period of copyright keeps increasing and more than 90 years is far too long to wait to change a license in the world of software.

This is why I don't quite get the "or later" clause. Sure it adds flexibility, but it basically trusts that the FSF won't do anything you're significantly unhappy with in future versions of the license.
In that case, license new version under GPL2, period and let the old versions become obsolete. The risk that the main point of the license "this software will always stay free" will change is close to zero and the "or later" clause is a safe bet to prevent license upgrade hassles.

The risk that the main point of the license "this software will always stay free" will change is close to zero and the "or later" clause is a safe bet to prevent license upgrade hassles

Well; for one thing, what is "free"?

Opinions may change. Whilst I agree that the chance of future versions being "non-free" is low, there is a non-zero risk that someone at the FSF may decide on a different version of "freedom" for future GPLs.

The BSDL is more "free" in a "do what you want with it" sense than the GPL.

"v2 or later" is *NOT* trivially convertable to "v3 or later." You either need all authors to agree to it, or you need to fork off the project and then convince all authors to work on the new fork.

The only practical benefit the clause provides is that a future v3 developer can incorporate v2 (but not v1) code. It's so that future versions can be backward compatiblity, not that past versions can be forward compatible.

For software that uses the phrase "or later" in its licence, I really fail to see the problem. "v2 or later" is basically a superset of "v3 or later""This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) version 2 or any later version.

What possible problem is there with that? It is logically identical to the existing rules, it just suggests GPL3 as the pref

You're confused. The actual statement is "either version 2 of the License, or (at your option) any later version".

There is no reason at all to believe that a version 3 would not be covered by that statement. And to say otherwise you'd have to show that the FSF did not intend this to cover future versions such as version 3, which they indeed did. Which is also why Linus chose not to include this statement.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or

(at your option) any later version.

As an author you needn't worry about having to pay licensing fees, since the GPL governs redistribution and doesn't take away the author's copyright. Furthermore, you needn't worry about people being forced to pay lice

Linux version 2.2, at least, didn't specify the GPL version, so that you can use any (including GPL v1). This presumably carries through; it's only 2.4-and-later additions that are difficult. Of course, 2.4-and-later additions are incredibly important to desktop users, so...

This is also a problem because it requires you to trust the Free Software Foundation to always make the right decisions. If your software is licensed with the "or later" clause, you might end up with it being licensed under terms you really don't agree with.

I think that current copyright law would not permit just switching over the liscence without contacting every contributor, since that would probably be a violation. But then again, im not a lawyer:)

Nor have you read the GPL

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or

Isn't most of the Linux kernel licensed under GPL 2 only? Doesn't that mean that, no, it can't fork, new license or not?

I mean, to fork it (to use GPL 3), you'd have to (for each file) find everybody who has ever made changes to that file (unless the changes have since been replaced) and get their permission to license that under GPL 3. If they refuse, you have to re-write the section that their changes are in (or the whole file). This doesn't seem realistic...

Does the Kernel require copyright assignments like GCC? I'd think this could allow the assignee to change the license etc. Not sure this is the case though: GCC development appears (IMHO) to be much more structured than the Kernel -- for better or worse.

...which has no bearing on the grandparent's post, which is about the Linux kernel.

The Linux kernel only makes most of itit available under v2 of the license:

Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

This all sounds very reasonable and careful. Why are the FSF people -esp. RMS- portrayed as being zealots here on/.?Of course they have an agenda. They may be (described as) somewhat fundamentalistic. But it seems that they are still arguing in very reasonable ways.

Because ad hominem attacks (e.g. calling someone a zealot) are easier than rational argument. I don't agree with Stallman on everything, and indeed he's one instance of someone who may actually be a zealot in the best sense of the term, but he does have a valid (I won't argue that it's correct, but merely that it's valid) philosophical basis for what he says and does. He's a very smart fellow, and he came up with a license which grants more rights to users than most licenses do, and in addition preserves

All I want is the ability to declare public and private interfaces for GPL products, where public interfaces can be used with any type of license and private interfaces are off-limits unless you're a GPL project.

All you have to do is distribute your program under the GPL, and provide a file saying "you are granted the rights to redistribute under the GPL, however you also are granted the right to link against this program and redistribute freely so long as you do so only via the interfaces declared in public_interface.h."

It is as simple as that. The Linux Kernel, as it happens, does almost exactly this.

Another option is that you could put some parts of your program (the "private" parts) under the GPL and other parts (the "public" parts) under the LGPL. I have seen programs that did exactly this.

The GPL does not restrict rights. It only grants them. As the copyright holder, you are of course free to grant as many other rights as you want in addition to the GPL rights. Of course, you can't speak for any other copyright holders that may have provided material in the program...

If there's GPL and LGPL code mixed in a program, then the program as a whole is licensed under the GPL.

However, the LGPLed parts are still just as LGPLed as they were before. The LGPL parts may then be detached and used in anything else you like. An example of this in action would be the KDE web browser Konqueror. Konqueror is under the GPL. However, portions of it (specifically the KHTML web rendering component) are licensed under the LGPL. You can't take Konqueror (or anything built using any of the GPL-licensed files in Konqueror) and distribute it without obeying the GPL. However, you can take KHTML-- which is an extremely useful piece of software-- build a new web browser around it, and resell it completely free of GPL obligations. Several commercial groups, such as Apple Computer, have done exactly this.

This obviously only works under some circumstances (for example, when the LGPLed component is something which can be detached and still be useful), but under some circumstances this is exactly what you want. I considered it worthy of mention because the toplevel post seemed to me to be very vague about exactly what it was he wanted.

You can if you own the copyright to the part you want to put under LGPL.Look at it like this. We'll used the BSD license because the differences are more drastic.

I can release my program under the GPL license or the BSD license. I can also put links to two different downloads of the same code, one of which has a COPYING that's the GPL and one that's BSD. Do you agree so far?

I can also distribute just the GPL version, and say "this is dual licensed under the GPL and BSD."

All you have to do is distribute your program under the GPL, and provide a file saying "you are granted the rights to redistribute under the GPL, however you also are granted the right to link against this program and redistribute freely so long as you do so only via the interfaces declared in public_interface.h."It is as simple as that. The Linux Kernel, as it happens, does almost exactly this.

Factually wrong. The kernel is GPLv2, straight up. It has an opinion from Linus on what constitutes a derivative w

I am not talking about programs. I am talking about kernel modules. Kernel modules link against the kernel directly, yet so long as they use a specific interface are allowed to consider themselves free from GPL obligations.The Linux Kernel mailing list FAQ: [kernel.org]

# What is this about GPLONLY symbols?

* (REG) By default, symbols are exported using EXPORT_SYMBOL, so they can be used by loadable modules. During the 2.4 series, a new export directive EXPORT_SYMBOL_GPL was added. This is al

wrong. it restricts some rights to preserve others. you can argue whether this is right or wrong, but that's what it does. and it doesn't grant any rights. the copyright holder already has all the rights in question. the GPL preserves some of those rights for people downstream of the copyright holder by restricting other rights for the same people.

It is not as simple as that, as your program with this additional permission cannot incorporate code of other programs released under the "pure" GPL. So your code can be used under "pure" GPL code (if you make this additional permission an option), but not the other way around (you cannot use "pure" GPL code and add this permission to the combined program).

This is not going to change. "Pure" GPL is what the people who released the "other programs released under the pure GPL" want. If the person who had rele

Yeah, but have you said it before to the people writing the new version? I think you should, since it strikes me as a good idea.

Also, you know you can write such a clause into your own projects (i.e. ones you own the copyright of), right? You may not want to because then it'll be "almost GPL" instead of GPL, but the option is there.

That's a very good idea... in theory. I suspect the implementation would be terrible. Why? The problem is with who decides whether an interface is public or private. If anyone is allowed to change that part of the code, it means that someone who wants to use the private interface can just change it to public, defeating the purpose of the thing. On the other hand, if you allow an author to create a private interface and prevent anyone from making it public, you create a mess worse than of the GFDL (see invar

We are talking about licencing, not SW engineering conventions. If you publish your source code, then your interfaces are by definition "public". I can go and read them, even the ones that you consider unstable and subject to change. I can code an implementation using one of those unstable interfaces, and have it interoperate with the particular release of the software. Since it's an interface and is "public" by virtue of the fact that I can see your code, there is nothing you can do about it. No court is g

With luck, the GPL v3 will clear up the issue of fonts [fsf.org]. The issue has been discussed on Slashdot before [slashdot.org].Namely, that if I use a GPL font in a document, and subsequently embed that font through a document format (OO's sxw or OpenDocument, pdf, ps, etc), it's unclear as to whether I have the legal ability to do so without declaring the document itself GPL (which isn't really a document license). People sometimes (apparently mistakenly, but IANAL) say that it would force your document to be GPLed, but that's really not the case. You can't be automatically forced to license your work as anything, but you can be guilty of copyright infringement. The issue does also apparently not extend to printed documents and such, since the font itself cannot be copyrighted, only the code (postscript, etc) that generates the font can be.

It's unfortunate that such vagueness persists with the GPL, but it seems to be a trend with copyright issues in general (fair use being the most visible).

No. The circumstances are different.Often when you embed a font in a document, you actually embed the truetype, postscript whatever source of the file, not just the output. That source is essentially a computer program; you could extract it and edit it, run it to generate images etc.

In fact, a comparison to an embedded game is more accurate. An early 32-bit version of Excel—95 or 97, I can't remember which—came complete with a complex easter egg (a 3D flight-sim type environment). This was an em

There is one concern that I don't hear people talk much about. I agree that people should be able to make modifications for their own use without having to provide anyone source code. I agree that source should only have to be given to people you give executables to. The problem I see is when a company gets the same classification as a person.

I'm have mixed feelings about the notion of a company owning a derived work with several people creating a derived work and many more people using it - and it's stil

Richard Stallman aims to 'lower barriers that today prevent the mixing of software covered by the GPL and other licenses.

This isn't as big a problem as Stallman makes it out to be. Combining open source licenses is not difficult. All you have to do is keep the pieces reasonably distinct. I have a project, for example, with a copyright notice that reads like this:

xxx is (c)2005 by blah blah and distributed under the terms of the GNU General Public License.

Does anyone have any idea how GPL3 intends to address Trusted Computing?Trusted Computing currently defeats the GPL and makes the source code effectively useless. If you attempt to modify and recompile the source (as the GPL ensures you the right to do) then the Trust chip denies the new code the key and the ability to read files. The Trust chip also announces over the internet the fact that you are running modified and incompatible software, so that the new software can be locked out on the internet.

Some people have expressed concern that organizations can take GPL'd code, modify it, and then run a web site with it. The act of running a web site using GPL code isn't considered distribution by the FSF, and the source code modifications therefore can be kept to themselves.

That's the argument. Personally, I don't know how I feel about it one way or the other.

Some people have expressed concern that organizations can take GPL'd code, modify it, and then run a web site with it. The act of running a web site using GPL code isn't considered distribution by the FSF, and the source code modifications therefore can be kept to themselves.

Running a web site isn't considered distribution by copyright either, and that's what really matters here. The GPL doesn't go into effect until you try to make a copy of the software, and even when it's in effect, you only have to distribute the source code to the people you distribute binaries to. If you only distribute it internally, then it really doesn't make a difference. Technically, a new version of the GPL could say that you have to give a copy of the code to the FSF if you want to distribute binaries at all, even within your own organization, but I don't think many people would actually want to use that license.

Personally, I think that making internal changes and not sharing them with the world is against the spirit of the GPL. People gave their work to you for free, and you don't want to give your changes back as payback? That's pretty lame. However, I don't think there's any practical way for a new version of the GPL to prevent it. Smart people try to get their changes accepted upsteam anyway so they don't have to maintain patches and make sure they apply and don't introduce new bugs. It's just less work.

Personally, I think that making internal changes and not sharing them with the world is against the spirit of the GPL.

Why do you think that? Do you think the same of companies that use GPL software *internally*? You've said yourself that this is okay, and in addition, RMS has gone out of his way to reject licenses that demand this. But what's the difference?

Applying the restrictions only within the legal domain of copyright **IS** the spirit of the GPL! To subsequently extend it beyond the domain of copyright to encompass the execution of software on servers is what is against the spirit of the GPL.

I'm sleepy. I think I made a mistake in my original post. To make a derivative work, you need permission from the author, usually in the form of a blanket license like the GPL. Theoretically, someone could come up with a license that says you must make public any derivative work you create. If this were the case with the GPL, then people running modified versions of GPL'd software on their servers would have to share their changes. It'd be hard to prove, but it could still be "required."

Because that's not the spirit. Read all RMS' voluminous rants if you don't believe me! Where you may be confused is because a lot of people, especially on slashdot, simplify it into "you must share everything". Instead, the spirit of the GPL is to share a certain *class* of changes. The current debate is whether changes to webapps fall into this class or not.

My point is that a blanket statement like "running a web site isn't considered distribution by copyright either" is not accurate. Even when you're talking about the implementation of some application via the web, e.g. Javascript code on a webpage is certainly covered by copyright.

WTF is wrong with using software that's distributed freely, spending your own time updating, then using it without redistributing it? If GPLv3 forbids that then it'll be going *way* beyond copyright law and even proprietary licenses.

Some people have expressed concern that organizations can take GPL'd code, modify it, and then run a web site with it. The act of running a web site using GPL code isn't considered distribution by the FSF, and the source code modifications therefore can be kept to themselves.To state the concern more clearly say EvilCompany takes gcc, does some crazy optimizations, and starts running it on their server never releasing the code, call it pgcc (propietary gcc). Then they sell a small app ttpgcc (talking to pro

I sure as hell wouldn't. The man doesn't live in the real world if he thinks open source will continue to thrive without GPL type licensing... just look at how booming the BSD community is compared to the Linux one...there's a reason for that.

I've got a longer version of my argument here [blogspot.com] if anyone cares to read it.

> I sure as hell wouldn't. The man doesn't live in the real world if he thinks open source will continue to thrive without GPL type licensing... just look at how booming the BSD community is compared to the Linux one...there's a reason for that.

Right now GPLv2 pays lipservice to patents but doesn't really have strong sanctions against companies who use them to quash free software. The provisions it has are weak and arguably unenforceable if the company distributing GPL'd software suddenly decides to cease.

Nokia, for example, may be able to get away with deciding to end its distribution of GNU/Linux, then suing anyone who's made a derivative version that violates a patent of their's in a way that versions they shipped didn't. Indeed, it's quite possible that a third party entering new code that infringes upon a Nokia patent, even today, could be stopped by Nokia.

(If anyone thinks I'm being unfair to Nokia, yes, unless they actually do this, then I am being, but at the same time they put out a very, very, guarded comment a few months ago that quite obviously left these scenarios open.)

What many people want to see is companies that use patents against free software unable to use a large body of free software from there on. That means a solution to the above issue, but also to, say, discourage suing in general by ensuring that if a company chooses to deny the use of a patented technology to one free software project, it chooses to deny itself the use of any. So if IBM sues to get a technology out of, let's say, Apache, it can't turn around and continue to distribute a (theoretically GPLv3'd) Linux kernel.

Software patents were not a serious problem when the first two GPLs were drafted, though I believe they existed by the time the second version was created. They are now, and they pose a serious threat to free software.

RMS doesn't want to forbid the distrobution of GPLed software for money. In fact, he's even said that it's okay to distribute for profit.

He just said that you need to include the source when you ship the binary copy. If he'd wanted everything to be free as in beer as well as free as in freedom, he would have written that into the license.

Agreed, the sale of free software is a bit difficult due to the redistrobution bit. However, it's not completely impossible. Look at RHEL: the source RPMs are the basis of several distrobutions.Of course, I do see the humor in your initial post, as well as your point. I'm just being incredibly pedantic. Free software is really a case of perfect competition as economics puts it: there is no long term economic profit in making free software. There is some in the short term, but it's been a semester or tw

Free software [development] does not appear to have any viable method of recouping development costs (particularly initial development costs).

Sure it does: if you want a particular feature developed, hire some programmers to write the necessary code. You just have to realize programmers are providing a service, rather than manufacturing a good.

RMS's philosophy is that software should be "free as in my definition of freedom". That definition of "freedom" just happens to include making selling software practically impossible.

Certainly, one effect of making software free to distribute is that it's hard to make money distributing it. But you seem to be going further than pointing out that obvious fact; you're insinuating that preventing people from making money is one of RMS's goals, rather than a side effect, and I don't believe you have any evidenc

RMS's philosophy is that software should be "free as in my definition of freedom". That definition of "freedom" just happens to include making selling software practically impossible.

RMS has nothing to do with it. It's up to the developer(s) of the software whether or not they want to use the GPL, and since it's their code and they can do whatever the fuck they want with it. If they don't want *you* to be able to take the code, wrap it into your proprietary product, and sell it without source then that's

In the real world most end users don't give a crap if the source is available.. they're not programmers. They want support (which the likes of IBM/Redhat give them) and they're prepared to pay to get it.

Because they tie their GPLed software to other products and services (their support contracts) - precisely as I pointed out they need to in my original post.

If Red Hat's only source of income was selling Linux, CentOS, WBL and various other free knockoffs would have run them out of business years ago (after all, why would you pay $$$$ to Red Hat when you could download an identical product for free ?).

It's still possible to make money from GPLed software. Ergo, RMS's job is not done.

You clearly have no idea what you are talking about.

The pupose of the GPL is to ensure that you are provided with the GPL licensed source of a program upon distribution. The program can cost a million dollars, as long as you get the source, under the GPL license.

Of course, you are perfectly within your rights to redistribute the program under the terms of the GPL. As this is the case it makes little sense to charge for GPL li

You're right that the GPL isn't entirely "free" in the "can do what the heck you want with it" sense. That would be more like the BSD license; or taken to its logical conclusion, releasing your software as "public domain".

Personally, I think that if people want to release their work under a BSD (or weaker) license, that's their choice. I just don't want to hear anyone bitch about it when such freely-available software gets incorporated into a proprietary product, and the company gives nothing back.

You're right; the GPL isn't "free"; it does, however, support the *preservation* of the *same level of freedom* that came with it in the first place. Contrast with BSD/public domain, which is more "free", but does nothing to *preserve* its freedom.

This is not correct. Code licensed under the BSD license has its "freedom preserved" - it will always be BSD licensed. *Modifications* to that code, *derivatives* of that code and products that utilise the functionality of that code, however, might not be.

What you are talking about is the *propogation* of "freedom", not the "preservation". The GPL *propogates* by requiring derivatives (with a ridiculously broad definition of "derivative", I might add) also be GPLed. The BSDL *preserves* by only applying to the code as it is originally released.

Depends on where your reference system is. For instance, if you're a developer joining an ongoing project previously released as GPL then you're liable to falling in the "GPL trap": the original authors can, provided t

Depends on where your reference system is. For instance, if you're a developer joining an ongoing project previously released as GPL then you're liable to falling in the "GPL trap": the original authors can, provided they get you to file papers giving up on any copyright on your code, relicense your code under a proprietary license. you might consider that Freeedom. I consider it freedom to make other people richer, and you poorer, i.e., slavery.

(My emphasis:-) For instance, if you're a developer joining an ongoing project previously released as GPL then you're liable to falling in the "GPL trap": the original authors can, provided they get you to file papers giving up on any copyright on your code

That's not a fault of the GPL- it's a fault over assigning the copyright/ownership of your code to someone else.

You don't have to do that. Of course, your modifications might not be accepted into the mainstream version. Your choice. It's nothing to

This is not correct. Code licensed under the BSD license has its "freedom preserved" - it will always be BSD licensed. *Modifications* to that code, *derivatives* of that code and products that utilise the functionality of that code, however, might not be.

You're right if you consider 'freedom' to only apply to the original code *as written*, and not the freedom of the "project". It does, however, make it very simple to create a piece of proprietary software from a piece of free software, and encourages n

They're trying to not mess up all the ways that GPLed code is used. That's not easy, because it's used a lot of different ways. And, they are trying to build a license that will not fail when subjected to the next ten years' worth of (currently) unknown attacks. (Look at how GPL 2 stood up under SCO's attack, and you'll see what I mean.)

This isn't just "slap together a license, and we'll fix it next week if we don't get it right the first time". Sinc

This is very important, as the GPL may not be enforceable on various countries as it is today. I know that, eg, in Brazil, special legal measures had to be taken to allow for the GPL to override (if the lic

Windows Vista will be out sooner!But seriously, people. Who gives a rat's behind?

Anyone who gives a "rat's behind" to office integration software ought to think about how you simply can't use GPL software to drive Windows out of its position. This is because there are literally thousands of applications developed to integrate with Microsoft Office, and they do so seamlessly.To do it under the GPL, you would have to develop a gigantic stack of software free software hackers simply know nothing about, unless