decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
LGPL - A change on the way
Thursday, July 13 2006 @ 04:50 PM EDT

I've been watching the videos from the GPLv3 conference in Barcelona, while waiting for SCO to file its appeal or request for reconsideration or whatever it turns out they will be filing today. Yes, today is the last day, and they really have to file if they wish to preserve what they view as an "error" -- whatever that may turn out to be -- for appeal at the end of the trial. If it ever goes to trial.

Anyway, while I'm waiting, I've been watching the conference sessions -- by the way you don't want to miss Carlo Piana on his Microsoft antitrust trial activities, including his assessment of Dr. Andrew Tridgell's testimony -- and in the video of Eben Moglen's speech [transcript] and the video of Richard Stallman's [transcript], they reveal that the next draft of the LGPL will include a change.

Instead of being a separate license, the LGPL will be the GPL with additional privileges, a kind of template of what additions should be. First Stallman:

One of the nice things this has enabled us to do is: we have been able to rewrite the Lesser GPL - the GNU LGPL - so that it uses this clause. The GNU Lesser GPL will not have to restate most of the things in the GPL, it will say it's the GNU GPL plus these added permissions. One of the other benefits we get from this is that we make it clear that any time someone adds extra permissions on top of the GNU GPL, that when you modify the program you can take off those added permissions. You can release your version under the strict GPL and nothing more.

We've also made it clear that it's impossible, it's self-contradictory, to try to add any requirements that are not in our list of what's allowed. From time to time people do that. They say "This program is available under the GNU GPL except you can't use it commercially." This is a self contradiction. The result is nonsense. You can't tell, even, what that really means because it's not clear what the licence would be for modified versions.

With GPL version 3, it's going to be clear that any added restrictions that the GPL doesn't allow for can be removed.

And then Moglen:

Some comment was made this morning about the LGPL as a section 7 additional permission on top of GPL. I would have left that subject to be disclosed when we show you the drafts in a couple of weeks, but as the subject has come up, let me just say one little thing about it. That move does not change the behaviour of LGPL at all, as Richard told you this morning. We adopted a non functional change constraint in the reshaping of the licence. What it does is to allow LGPL to serve as a good example of the additional permissions structure for GPL and how powerful it is. By expressing LGPL as just an additional permission on top of GPL we simplify our licensing landscape drastically.

It's like for physics getting rid of a force, right? We just unified electro-weak, ok? The grand unified field theory still escapes us until the document licences too are just additional permissions on top of GPL. I don't know how we'll ever get there, that's gravity, it's really hard. But the physics has gotten simpler and, I think, that alone is valuable. The other thing is that the new LGPL expressed as permission will show people how to use permissions to make quite sophisticated licences very simply, and we think that also is all to the good because such licences do not proliferate, they reconvert to GPL at the instance of modifiers which is a valuable and useful property to have.

From what Moglen says, and it's too long to quote here, I gather he thinks they've found a good solution to the DMCA/DRM problem which we'll see in the next draft. He also mentions, by the way, that there have been some extremely valuable suggestions made by the public. He presents as an example the following:

Let me give you one example of an important issue unearthed in the public comment process which will have an effect on the second discussion draft of the licence.

As you all know, since the beginning of the licence it has concentrated a great deal of attention on distribution as the moment at which obligations attached to your role in the free community. The assumption has always been that distribution is a one way activity. Somebody distributes, and the user receives. If binaries are being distributed, in particular, the binary distributor has an obligation to make source code available to a receiving user.

All of this make great deal of sense in 1991 and it probably still makes great deal of sense in 2006, but. Consider the situation of an iso image of a cd containing binaries of Free Software material under GPL being distributed among persons by BitTorrent. If you think about that scenario for just a moment you will see that in the torrent are a bunch of people "distributing binaries" who don't think of themselves as distributors, who think of themselves as users receiving the binaries who have no source code and who haven't even got all the binary, yet. So that even if source code will later be part of the same torrent they're not guaranted to have it and they can't pass it along.

Under GPL2, an unaffiliated commentator said to us, this would be infringing activity, why don't you do something about that in GPL3?

We looked at it and said, "you know, you're right". That's a major problem. That is to say, it's not all that hard to fix, but it's a major problem not to have seen it, "we are glad you brought it up".

And we will make a few very narrow changes in the second discussion draft of GPL3 to allow from the fact that peer-to-peer models of distribution may involve ancillary transmission by people who would traditionally have been thought as were receivers and they shouldn't have any obligations under the licence, because they are not actually engaged, in the sense we used to mean, in 'distribution'.

That's for example an important technical issue in the changing, use and context of the licence, raised by somebody from outside the process and, as I said, there are probably two or three more of equivalently important scope that I could point to. That kind of commentary is worth its weight in gold. It is because of that kind of commentary from unaffiliated individuals that the entire process is worth to maintaining, cost-what-it-will, to maintain it, to read its output, to think about every word it says, that's exactly what we were hoping for, that's exactly what we are getting.

So if that was you, they heard you. The videos are Theora.ogg format, and if you aren't sure how to play them, VLC works on Windows and Macs, and it plays Theora. If you are interested in participating, here's where you go. As Fernanda Weiden states in the panel she moderates, even if you have only a small idea or suggestion, others can build on the idea, so don't hesitate to share it. If it stays only in your brain, no one can access it there.

I also found what Moglen says to the final questioner of interest:

It generally turns out, as I know from having spent almost a quarter of a century now as a lawyer for hackers, that when hackers pretend to be lawyers, there are certain predictable formulations that they come to; they assume a degree of consistence in legal rules that is not achievable; this is a primary problem which occurs particularly in US focused conversation, such is that in Debian Legal, where the libertarian demand for intellectual consistency, and the hacker belief that laws are form of code that are executed without errors or ambiguities, joins together to create a particular frame of analysis for legal questions.

It doesn't work very well for me as a lawyer, I think it doesn't work very well for lawyers elsewhere in the World, because the one thing which lawyers around the world all share is an awareness of the squishiness of law, it is by no means the hard arthropod carapace for internal soft organs that non-lawyers have a tendency to assume it is....

The question to be asked within the Free Software Foundation's ethics of law is not "Is this a restriction on freedom?", which is what I think I heard the Debian Legal analysis is doing, the question is: "If this is a restriction of freedom, is this the narrowest possible restriction to protect freedom in the long run, or is there a narrower way to accomplish the same protection of freedom, or is it better to allow freedom to be defeated in the long run than to impose this restriction now?".

But it is always, I think, in Free Software Foundation thought, it is certainly characteristic of Mr. Stallman's thought throughout his career, it is characteristic, I think, to be minimalist about restriction, not negative about restriction.

The position being taken is "to have a community requires some minimum restrictions to preserve community". We tend to see the other side's view of that question "there ought to be no restriction except those which are inevitable" as too libertarian to be firmly communal. If you want to keep a community in being you may have to say "clean up after your dog on the sidewalk".


  


LGPL - A change on the way | 163 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here please
Authored by: MadScientist on Thursday, July 13 2006 @ 04:58 PM EDT

[ Reply to This | # ]

OT materials here please
Authored by: MadScientist on Thursday, July 13 2006 @ 05:00 PM EDT
If you want to provide a link please use the HTML post mode. See the bottom of
the posting page for details.

[ Reply to This | # ]

LGPL - A change on the way - this is a good thing
Authored by: dyfet on Thursday, July 13 2006 @ 05:12 PM EDT
There have been many minor issues with the original LGPL and the strong focus purely on code linking. The most glaring limitation has been the inability to have a LGPL "effect" for class frameworks written in object oriented languages which may mix inline headers & methods, and aggrigate user code and library frameworks together in ways other than what is considered pure C/assembly style linking.

One result of this has been a "fork" of the GPL known as the Runtime GPL license, which is what the GNU implimentation of the C++ standard library (as distributed with the GNU Compiler Collection (gcc)) uses. Some C++ projects choose in the late 90's explicitly choose instead to use the MPL license (the best known example being OpenH323) given the limitations in the original L-GPL language, and before the R-GPL became widely known and used. Other C++ projects used the GNU GPL with Guile license exceptions, which essentially is what the R-GPL now does with using more current language. All these things have created ambiguity and confusion where having a core GPL with standardized permissions to create a LGPL "effect", and one with language which supports modern programming languages and practices, would have been much better.

[ Reply to This | # ]

  • Open H323 - Authored by: Anonymous on Thursday, July 13 2006 @ 05:15 PM EDT
Today?
Authored by: rsteinmetz70112 on Thursday, July 13 2006 @ 05:22 PM EDT
Today is 10 days from the date Wells signed the order.

I though it was 10 days from the date they were served. Was SCOG served that
same day? It seems likely they didn't get it the same day.

I'm not sure of the process for issuing and serving a judges order.

---
Rsteinmetz - IANAL therefore my opinions are illegal.

"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk

[ Reply to This | # ]

LGPL - A change on the way
Authored by: Anonymous on Thursday, July 13 2006 @ 05:33 PM EDT
Are these video's available anywhere not via torrent? I can't use bittorrent
from where I am, it's blocked.

I really want to watch these presentations, because I'm about to release a
pretty hefty Open Source project, and I want to know where GPL 3 is going
(picking licences is no trivial matter, is it). Watching these presentations
would be a big help.


Skip (still no luck getting my password right, so not logged in)

[ Reply to This | # ]

LGPL - A change on the way
Authored by: Anonymous on Thursday, July 13 2006 @ 05:48 PM EDT

Quoth rms: "With GPL version 3, it's going to be clear that any added restrictions that the GPL doesn't allow for can be removed."

How? IANAL, but if somebody gives you contradictory information on what you can and cannot legally do with a program they wrote, why would it be acceptable/legal for you to selectively disregard those parts of the license text you don't like?

Again, IANAL, and maybe I'm expecting copyright law to make more sense than it actually does, but I'd think that the outcome in this case should be that since you cannot determine whether you do indeed have a license to do the kinds of things that you need a license for, you cannot do these things at all. A self-contradictory license is not a license at all, so you should only be able to do what copyright itself allows you to do.

Or not? Maybe I'm wrong, but no matter what, I don't think that you can simply ignore parts of a license text that contradicts itself.

[ Reply to This | # ]

GPL and Comments
Authored by: Araneidae on Thursday, July 13 2006 @ 05:54 PM EDT

Can anybody comment on the place of comments and associated documentation in the GPL? I am faced with a rather curious situation where a device driver is being distributed by the vendor in two forms: complete with comments under non-disclosure terms, and under GPL with all the comments stripped out! This appears to allow them to claim that the driver is "GPL" and thus the kernel is untainted.

Is this really valid under the terms of the GPL? I've looked at the license, and I can't see an obstacle, but it seems dishonest.

After all, if this is allowed, then what's to stop somebody publishing completely incomprehensible obfuscated code as part of their fulfillment of the GPL obligation?

[ Reply to This | # ]

Dual licensing..
Authored by: Anonymous on Thursday, July 13 2006 @ 08:34 PM EDT
"This program is available under the GNU GPL except you can't use it
commercially."

This is something I have seen quite few times and I was wondering about it. J2ME
Polish and, I think, Trolltech QT have dual licensing mixing up GPL (v2?) and
commercial license. You either pay up or you don't use it commercially. It makes
no sense to me from what I know about GPL but I may be wrong..

anyone to clear us up on this scheme?

[ Reply to This | # ]

IAAL - I agree with Moglen
Authored by: Anonymous on Thursday, July 13 2006 @ 10:34 PM EDT
He has summarised succinctly why reading some comments on Groklaw make me want
to scream in apoplectic and impotent rage.

The law is not code and so is not logical or internally consistent in a way that
equates to that of a designed (hopefully) programming language. Also, the law
does not, in any way, resemble the “laws of nature”. The law regarding
copyright is nothing like Newton’s third law of motion. One has emerged after
decades of arguing and the taking and defending of positions. The other is an
attempt to understand and reduce a natural interaction to a simple definition.
It is a category error based on linguistic confusion to mix the two up.

This of course means that he says there is usually no black and white solution
to the problems found in licensing questions or copyright. And that’s the way
that many lawyers like it I am afraid.

PS: this is not meant to put down coders or scientists; I thought the same
before becoming a lawyer and often wish I had carried on with physics instead.

[ Reply to This | # ]

LGPL - A change for the worse?
Authored by: Anonymous on Friday, July 14 2006 @ 06:32 AM EDT
Lets consider the scenario:

I've written a body of code - a library that I release under the lgpl because I
want other people to be able to benefit from that work and to share and benefit
for myself and my projects from any potential work that's done.

That library is used extensivley in a non-gpl project (be it open source or
propriatory).

Now someone else comes along and makes a significantly beneficial change to the
library that requires an interface change... and then they decide to release the
library as a whole under the GPL rather than the lgpl.

I'm now barred from sharing in the rounds of mutual benefit because someone has
decided to remove permissions that I've expressly given to code I've written.

My strong immediate reaction is that this is IMHO simply wrong. Here we have a
system that appears to be designed so that projects that are started under the
lgpl can be easily and subversivley coerced into becoming full gpl project.

This to me appears like a 'submarine license' and wouldn't be something I'd be
happy putting my code under if I wanted to simply share some stuff but needed
(for whatever reason and there are lots of good reasons) to keep other things
closed.

How have I misunderstood this, this can't be what they're saying?

[ Reply to This | # ]

LGPL - Potential trap
Authored by: drorh on Friday, July 14 2006 @ 06:34 AM EDT
Assuming the goal of LGPL is to push some technology or implementation beyond
the free software range to the wider industry, I see a possible trap with LGPL
becoming GPL with some additional permissions. If I correctly understood the
intention, anyone can make a change and revert back to the original, basic GPL.
So if someone uses a new-LGPLed library (or framework) in their commercial
product they face a risk that some further version of this library (e.g. with a
fix or extension) will suddendly become basic GPL without the 'library'
provisions.

[ Reply to This | # ]

LGPL - A change on the way
Authored by: iabervon on Friday, July 14 2006 @ 12:17 PM EDT
If you read Linus Torvalds explanation of what he did with the license for
"sparse" (his C parsing/static checking library), you'll see that he
didn't choose the LGPL for exactly this reason: he cared that people be able to
make LGPL-style use of library versions derived from what he was writing,
including uses not permitted by the GPL, so the clause that lets people make
derivative works under the GPL instead of the license they get was a
deal-breaker for him, and this was with the present LGPL. Of course, this aspect
of the LGPL isn't particularly well known.

I like the idea of merging the LGPL and GPL, though, because it raises the
possibility of a Creative Commons-style arrangement, where there's a
standardized document with a bunch of optional features, and a licensor can
specify exactly what terms he or she wants to give by picking clauses in
standard language to include. So there could be a version that says: "GPL +
(the LGPL grant) + (grants must stay the same)", and this wouldn't require
licensees to understand a whole new license; the author would just say "GPL
+ linking + share-alike" and it wouldn't be a whole new document that
people would have to pick through for weird clauses.

[ Reply to This | # ]

Wish he wouldn't slander debian-legal.
Authored by: Anonymous on Monday, July 17 2006 @ 02:39 AM EDT
<blockquote>they assume a degree of consistence in legal
rules that is not achievable; this is a primary problem
which occurs particularly in US focused conversation, such
is that in Debian Legal, where the libertarian demand for
intellectual consistency, and the hacker belief that laws
are form of code that are executed without errors or
ambiguities, joins together to create a particular frame
of analysis for legal questions.</blockquote>

Well.... he's misunderstood.

In *contract law*, which is the main context in which
copyright licenses end up being examined, there's
something called *writing a contract*. You can draft a
vague and confusing contract, in which case the courts
will eventually decide what it means. This is actually
popular among many businesses, who want a contract which
appears to mean one thing to one party and one thing to
another; and they hope that the issue of what it actually
means will never really come up.

Or you can draft a clear and unambiguous contract which
does not overreach, in which case the courts will uphold
it. Or you can draft an unfair contract, in which cast
the courts may, if you're lucky, throw out the unfair
clauses.

Debian-legal would like it if all the software licenses
were clear, unambiguous, and fair. After all, non-lawyers
have to read and understand them in order to make use of
the permissions granted by them.

When we say that a particular clause appears to allow for
some nasty restriction on freedom, we aren't saying that
it *definitely* allows for that restriction: we're saying
that it *might*, and that we don't want to deal with that
ambiguity. For this reason, a clarification from the
licensor saying "No, I don't mean that" is always
sufficient: it removes the ambiguity. However, for
licenses which are going to be reused by many licensors,
this becomes tedious in the extreme, so we would like to
avoid ambiguous licenses in the first place.

This is not like interpreting law, it's more like
*writing* it. Hackers can *choose* the license they
license their work under, and we'd like them to make a
good choice. If we are paranoid about preferring licenses
which have no room for ambiguity of interpretation, it is
because we are not the final interpreters; the courts are,
and we don't want to have to guess what they'll do with an
ambiguity.

<blockquote>The question to be asked within the Free
Software Foundation's ethics of law is not "Is this a
restriction on freedom?", which is what I think I heard
the Debian Legal analysis is doing,</blockquote>

No, that's "step one". That is also step one for the FSF.
If it's not a restriction on freedom, then it's a fine
license condition, of course....

<blockquote>the question is: "If this is a restriction of
freedom, is this the narrowest possible restriction to
protect freedom in the long run,</blockquote>

And he just skipped a step. Step two is "Does this
restriction act to promote freedom in the long run, or
does it have no actual significant benefit for freedom?"

Many, many clauses to which debian-legal objects fail this
second step: they do not promote freedom, even indirectly.
Consider the clauses in some licenses which waive the
right to trial by jury. Consider also the "Invariant
Section" rules in the GFDL. Et cetera.

Step *three* is then to ask whether this is the narrowest
possible restriction. This requirement is failed by a
number of other clauses, such as the overbroad DRM clause
in the GFDL, the overbroad patent retaliation clauses
which aren't restricted to software patents, etc.

Consider also choice-of-venue provisions which apply to
suits brought by the licensor against licensees; these are
manifestly ripe for abuse if courts accept them, and have
no positive function: a choice-of-venue which applies only
to suits brought against the licensor may provide a
positive function, but a broader one is simply overbroad.

"or is there a narrower way to accomplish the same
protection of freedom, or is it better to allow freedom to
be defeated in the long run than to impose this
restriction now?".

Yes, this is what debian-legal asks, and we also usually
answer it (with better-drafted clauses) because nobody
else seriously tries to. Certainly the FSF hasn't tried
to recently. We'd certainly welcome it.

Debian-legal had an excellent conversation with a Scottish
lawyer (Jonathan Mitchell, QC, I believe) who drafted the
Scottish version of the CC licenses. Scotland requires
that licenses be in "plain English". He accepted
essentially all of the points where we suggested narrower,
less restrictive clauses which said exactly what they
meant, not something else; and he explained to us the
points where we had misunderstood legal terms or rules.

Result? A license text any lawyer and any hacker would be
happy with.

I think it is the hackers outside debian-legal who write
license texts who make the error of treating licenses like
code -- not the relatively thoughtful people on
debian-legal. A maxim which debian-legal has come up with
is "Don't specify means, specify ends." If you want to
require that modified versions retain your authorship
credit, require that: don't require that the "AUTHORS"
file be retained unchanged. A large number of the clauses
about which debian-legal has complained are exactly of
this variety and can be fixed in exactly this manner.

Now, it's true that a court might well decide that
renaming the AUTHORS file wasn't a "real" violation of the
license. But on the other hand it might not: it's a weird
question, and courts are likely to get confused by it,
with long arguments about the intent of the licensor.

So why not just get it right when drafting the license?
Say what you mean. Then it's up to the court to determine
whether the authorship credit was in fact retained or
deliberately removed -- which is the sort of question
courts are *very good* at deciding, based on the actual
facts of the case, the personal element, etc.; the sort of
question courts are asked to decide all the time, and
which is usually quite easy to determine.

In ways like this, debian-legal is actually asking for
MORE "squishiness" in licenses. "Retain accurate
authorship credit" is "squishy" in the way the law
*should* be squishy: consideration for facts of the
individual case -- without being "squishy" in the way it
shouldn't be, namely being confusing or saying something
it doesn't mean.

[ Reply to This | # ]

LGPL - A change on the way
Authored by: Anonymous on Monday, July 17 2006 @ 07:33 AM EDT
I think the way it works with QT and whatever is that legally, you can get two
separate distributions (of the same software, but that isn't really a concern)
where one of them is just plain GPL'ed and hence you can't use it for
closed-source, and the other is the one you get after paying up, which has
different license texts attached.

This will always work with the GPLv3 as well since the two QT distributions
would essentially be separate works (and I seem to remember that when Borland
did this, they actually were separate works and the GPL version of the runtime
would force a GPL statement in a --license parameter or such)

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )