|
|
| More on GPL 3 |
 |
|
Thursday, September 29 2005 @ 01:20 AM EDT
|
There's a lengthy ONLamp interview with Richard Stallman, "RMS: The GNU GPL Is Here to Stay," and I thought it was important to highlight one part, the legal portion of the interview about the upcoming GPL version 3, because many of you will face decisions about it, whether to use version 3 or stay with version 2, how to handle patches, and things like that. But you'll likely want to read the entire interview.
Here are the parts I thought most useful: Question: A lot of free software projects choose to use the following phrase in every of their program files:
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.
But this means:
1. The user will choose which particular version of GPL he prefers, not the original software author.
2. The user could choose this moving target (GPL 2.0, 2.1, 2.x, 3.x) appropriately in case of a lawsuit.
How can this undefined condition be a good thing?
Stallman: This achieves two goals. First, that we can release future GPL versions and they will apply to the existing software. Second, that in releasing future GPL versions, we cannot impose any new restrictions on the existing software.
GPL version 3 will need to contain specific requirements that GPL version 2 does not have. Nothing large -- the overall idea will be the same -- but there will be some. I designed the words you've quoted to make it possible to distribute the existing code under GPL version 3, without imposing even the smallest new requirement on existing code, because people will still be able to use it under GPL version 2. . . .
Q: What type of compatibility and interaction will GPL 3 have with previous version of the license? Stallman: Even small changes from version 2 of the GPL will result in an incompatible license. Two slightly different licenses, each saying that modified versions of a program must be distributed under the same license, are inevitably incompatible. That's why we suggest that programs permit use of future versions of the GPL. It is the only way they can migrate. . . .
Q: Maybe you could talk about the common question that people have: a project under GPL that receives a patch under GPL 3. What happens?
Stallman: If the project's current code permits use under "GPL version 2 or later," they can integrate that patch. However, the files where they have merged in the patch will have to say "GPL version 3 or later."
They also have the option of not using that patch, or asking the contributor to give permission for its use under "GPL version 2 or later."
Q: If I take a patch under GPL 3 and merge it with a project under "GPL 2 or later," should I write that the new license for the whole project is GPL 3?
Stallman:
The merged program as a whole can only be used under GPL 3. However, the files you did not change could still carry the license of "GPL 2 or later." You could change them or not, as you wish.
Q: And then include GPL 3 in the file named COPYING?
Stallman: Yes, you should include a copy of GPL 3. If some files remained under "GPL 2 or later," then you should also include a copy of GPL 2. . . .
Q: What type of clauses do you plan to add to fight "Treacherous Computing"?
Stallman: Nothing we put in free software licenses can block the implementation of Treacherous Computing inside a computer, just as nothing we put in free software licenses can prevent the existence of software patents. The only thing our licenses can affect is whether those threats can pervert the nature of our software. Thus, we are thinking about a clause requiring distribution, with the software, of any signature keys necessary to sign the binary so that it can run and fully utilize the machine's facilities. This would prevent the perversion of a supposedly "free" program, which nominally you are allowed to change, except that modified versions are prevented from functioning.
The strategic decision of whether such a requirement is a good idea is very difficult. No one can reach any conclusions about GPL version 3 until it is completed, but it's good to begin thinking about it now, so as to meaningfully contribute to the community input about GPL 3, but also so as to utilize the GPL properly.
|
|
|
|
| Authored by: iceworm on Thursday, September 29 2005 @ 01:41 AM EDT |
Get your corrections here!
Log in first! [ Reply to This | # ]
|
| |
| Authored by: DaveF on Thursday, September 29 2005 @ 02:12 AM EDT |
Make your links clickable as per the instructions...
---
Imbibio, ergo sum[ Reply to This | # ]
|
| |
| Authored by: vruz on Thursday, September 29 2005 @ 03:28 AM EDT |
so far so good, the more I hear about the GPL3 the more I like it.
yet I have some concerns from what RMS said, and I found me questioning myself
what are the implications.
1) introducing code signing would require a particular
protocol/procedure/technology to be specified.
this has many side effects that are very hard to tackle, and nearly impossible
to predict without narrowing the scope of the feature
some effects I can think of:
a) software complexity, would we have to have a GNU-sanctioned piece of software
in order to mark GPL'd code ?
how is this different from something like "DRM for binaries" ? (not
trying to FUD here, trying to get the full picture) wouldn't it we be
introducing complexity that is doomed to be broken anyway ?
until now, everything a developer had to do under GPL 1 and 2 was to deliver
appropriate licences in plain text files along with the sources (and/or
binaries)
this has worked wonders so far, is there a real need to face the possible
exponential growth of complexity involved with digital signs ?
b) legal complexity
the doctrine of authorisation can be tricky to handle in the real world, what
happens when I rebuild some software I got in source from another developer ?
will we have a trail of signatures and hierarchies/authorities ? how do we track
responsability and liability ?
hierarchies don't map too well here.
2) Linux and other very important GPL'd software
will Linux be (at Linus' and others' option) compatible with the GPL3 ?
how will companies and the many kernel devels. agree on this ?
I don't know whether the scenario presented by RMS is realistic, if Linux were
GPL3-ed asking people to specifically support the GPL3 or GPL2-and-later or
GPL1-and-later.
what would be the impact on Linux development ?
minimal ? considerable ? null ?
in case Linus and the devels agree to support GPLX-and-later, can the switch be
coordinated between GNU and the OSDL ?
ok, please note that this is just some quick impressions/thoughts I've had from
what RMS just said, really, not a simple thing to solve at all.
let me know if I'm missing the point.
---
--- the vruz[ Reply to This | # ]
|
| |
| Authored by: Fredric on Thursday, September 29 2005 @ 03:53 AM EDT |
What if I modify and redistribute some software where the license terms contains
that phrase:
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
that RMS suggested.
Do _I_
have to choose or could I simply pass the phrase on? I can not see how the
latter would be possible given the terms stipulated by that phrase.
Would
this mean that GPL3 must contain some similar phrase to make it flexible enough
and, if so, does that not make GPL3 more or less meaningless?
I am confused.
Does anybody remeber if the transition between GPL1 and 2 contained simlar
problems?
---
/Fredric Fredricson
--------
[Funny sig temporarily removed for tests on Salisbury Plain] [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Thursday, September 29 2005 @ 04:36 AM EDT |
My 1st concern was the requirement of supplying all relevant information
required to make a binary built from the supplied source 100% compatable and as
functional with the binaries you distribute.
Some applications use 3rd party securty static libraries built into their
binaries to prevent someone using the source to create inappropriate
equivalent.
An example was a GPL quake project who's servers would only allow the binaires
they built to connect to their servers to prevent cheat clients.
Another example is a GPL based IRCD that also uses a 3rd party security
libraries to help protect the network it is used on.
Both are these are certainly buildable from source, the resulting binary does
work but lacks the security features of the binary equivalent.
The problem arises when the 3rd party security library is closes source, isn't
"freely" distributable outside the binary that it contains, and
doesn't make public the information it uses to validate the binaries.
Another concern I had with GPL3 was the fact that now they are gonna add in a
usage clause in reguards to web apps that would require the site running it to
allow used to download the source. Even though the site wasn't distributing it.
This is apparently being done so that any enhancements that were made to the
gpl3'd web apps specific for that site would be freely available.
The problem here is that although I'm not "sharing" by distributing
the software, any changes I make I hae to share if I let anyone access the web
app. (Note: access in the sense that if I modified my apache webserver, and if
it was under gpl3, I would be required to make those changes available is I
allowed anyone to connect to the server)
While I do see the positives and intentions of the changes I've spoken about, I
also see the negative and I myself as a developer will be moving away from GPL
if these 2 changes do make it into GPL3 due to the restrictions they will place
on me.
Example, I have active GPL based servers which I use to test different things on
the internet. They are cut down versions of daemons you might find in a linux
dist.
I do not distribute them as they are specific testing vehicles for other
projects I work with and do-not wish to distribute the messy source I've created
with them.
However all these are accessable from the web as different times, and with that
being the case, if I developed ones based on GPL3, I would have to make the
source available reguardless of its usability or relavance to the original.[ Reply to This | # ]
|
| |
| Authored by: dyfet on Thursday, September 29 2005 @ 07:05 AM EDT |
| I believe what RMS means is that if a key is needed to sign for the binary,
then it is, like source, a material piece of knowledge that is required to
produce a running program, then it, like the source code, should be
redistributed so that users can claim full freedom in using your software. At
least that is how I parsed and interpreted what he said. This does not say
anything about specific methodologies, just simply that all the pieces
required to produce an actually runnable program from the source provided
must
be distributed. To do less would be like deliberately refusing to
distribute a
specific (missing) source file in the source distribution.
How this applies
to specific TDM implimentations I am not sure. I think
perhaps one thing he is
concerned with is the idea that a separate authority
may sign and authorize
keys for binaries, and so only pre-authorized and
pre-signed keys could be
used, so the person receiving the source and
wishing to reclaim his rights may
not be able to do so. I am uncertain how it
applies in some specific cases,
since presumably if the source is modified, the
resulting binary would be
different, and hence would a different authorized
signature key then be needed
or need to be signed for also?
While they sound harmless on the surface, one
of the principle risks with
code signing concepts is the idea that a central
signing authority must sign
your keys, and hence can control what software is
even permitted to exist.
Barriers could be imposed either by fees, or by
direct refusal. GPG has a
wonderful model for distributed trusts with the
ability to start from self-
generated keys and letting the user decide who's
keys they will trust rather
than requiring a central authority to do this, but
I suspect those interested in
TDM and code signing are not particularly
interested in that kind of model.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Thursday, September 29 2005 @ 07:10 AM EDT |
Excuse my ignorance, but what is to prevent another group or organisation from
issuing their own new version of the GPL? Could such an update alter the
characteristics of the license?
Just curious, as the interviewer's first question to RMS reflects a lot of
puzzlement I've had over this wording for some time...[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Thursday, September 29 2005 @ 02:36 PM EDT |
...of "GPL 2 or later."
I would prefer "GPL 2 AND later." If you agree to "GPL 2 or
later.", you agree to accept a license that hasn't been written yet. You
agree to give up your rights under GPL 2 in order to gain the rights granted by
GPL 3,4,5,etc. "GPL 2 AND later" would continue to provide the
protection of GPL 2 while adding additional protection of GPL 3,4,5,etc. What
if GPL 4 transfers all copyrights to RMS? "GPL 2 or later" allows
that to happen.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, October 01 2005 @ 03:43 AM EDT |
I just wish the GNU GPL v. 3 was being written in a free,
open manner, rather than by a secret cabal behind closed
doors.
Sadly, RMS doesn't seem to have seen the practical
benefits of free software methods in other areas. If you
want an iron-clad license which does exactly what you want
it to, you don't go to one lawyer. You get it vetted by
as many people as you can.
[ Reply to This | # ]
|
|
|
|
|
