issues with the AGPL
Bill Allombert
I'd like to share two issue I found with the AGPL, for the record.
REFERENCES:
The GNU Affero General Public License (AGPL) is essentially the GNU General
Public License with the following additional clause reproduced below.
See http://www.fsf.org/licensing/licenses/agpl.html for the full text
of the license.
""
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users interacting
with it remotely through a computer network (if your version supports such
interaction) an opportunity to receive the Corresponding Source of your
version
by providing access to the Corresponding Source from a network server at no
charge, through some standard or customary means of facilitating copying of
software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is
incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to
link or combine any covered work with a work licensed under version 3 of the
GNU General Public License into a single combined work, and to convey the
resulting work. The terms of this License will continue to apply to the part
which is the covered work, but the work with which it is combined will remain
governed by version 3 of the GNU General Public License.
""
ISSUES:
0) Conflict with the The Free Software Definition:
<http://www.gnu.org/philosophy/free-sw.html>
The AGPL is in direct conflicts with the two paragraphs below:
You should also have the freedom to make modifications and use them
privately in your own work or play, without even mentioning that they
exist. If you do publish your changes, you should not be required to
notify anyone in particular, or in any particular way.
However, rules about how to package a modified version are acceptable,
if they don't substantively limit your freedom to release modified
versions, or your freedom to make and use modified versions privately.
Rules that "if you make your version available in this way, you must
make it available in that way also" can be acceptable too, on the same
condition. (Note that such a rule still leaves you the choice of
whether to publish your version at all.) Rules that require release of
source code to the users for versions that you put into public use are
also acceptable. It is also acceptable for the license to require that,
if you have distributed a modified version and a previous developer
asks for a copy of it, you must send one, or that you identify yourself
on your modifications.
The AGPL seriously restrict your ability to make public version.
1) Clause 13 creates obligations for the persons who has modified the software,
even when they stopped using it and stopped to distribute it.
Suppose Alice modifies the software and distributes it in source form to
Bill. Alice stops to use the software. Bill starts using the software on a
server. Since it is Alice which modified the software, it is Alice which has
to satisfy clause 13, and thus to provide access to the Corresponding Source,
as long as Bill is using Alice version.
This is extremly onerous to Alice.
1 bis) it is Alice which is responsible for the runtime behaviour of the
modified software run by Bill, even though Bill can run it unmodified in
an environment which can cause it to perform differently than on Alice
computer, and not display prominently an offer for the Corresponding Source.
This is a risk to Alice.
2) The wording "your modified version must prominently offer " is
very strange: a modified version is not a legal entity that can offer
anything, let alone make good on an offer. So either the AGPL require the
modified version to be raised to AI level, or that the offer does not need
to be fulfilled.
3) The AGPL does not specify if the "computer network" and the "network
server" must be part of the same network. If yes, you might be forced to
provide the Corresponding Source on all non-internet connected networks someone
use your software on. If not, you can provide it from a network server where
noone has access to.
4) I find pretty alarming that the one situation where providing the
Corresponding Source is easy (where the program is a perl CGI script and you
just need to configure apache to allow users to download it from the /cgi-bin
directory and having it displays a link) is not suitable for the AGPL because
the program cannot force the webserver to allow such download.
5) Is recompiling a software modifying it for the AGPL ?
(Full disclosure: there is a GR proposal pending on this topic, with a
different rationale)
Cheers,
--
Bill. <ball...@debian.org> "Please CC me"
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Greg Harris
The AGPL has been the topic of multiple extended and heated discussions
during my short time subscribed to this list. If you are interested in
actual comments, you may want to review the previous discussions. If
you are interested in renewed (and to my mind unproductive) bouts of
rehashing these questions, no doubt you will get that result as well.
From a purely personal perspective, I just don't see the problem.
Authors who choose to license their work under the AGPL have a desire
not to see derivative works locked up inside a walled garden under some
pretense that those derivative works are not "distributed" when they
are offered for public user interaction. There is nothing in that goal
that is in any way incompatible with the goals of the GPL. (As you
quote: "Rules that require release of source code to the users for
versions that you put into public use are also acceptable.")
With respect to your identified problems, Alice would have been under
an obligation to provide source code for her derived version to Bill.
When Bill distributes (and that, really, is what we are talking about
here) a modified derivative version to public users, Bill undertakes an
obligation to make available the source code to those users. I do not
see anywhere a basis to invent any ongoing obligation for Alice.
Similarly, if the AGPL does not specify that modified source code must
be made available from the same or a different network, that
emphatically is not a shortcoming. It can be either, or both, but not
none.
Your items (2) and (4) are, frankly, mystifying. If those are
intended to represent actual concerns, you have not explained them
in a way that I can understand. (Your fifth issue leads me to suspect
that none of them are concrete problems. Does a mere recompiling alter
the source code? How does this raise any issue concerning the AGPL that
does not also effect other licenses?)
I do not profess any expertise or experience with Debian policies other
than a general reading. Nor do I think of myself as a defender or
critic of any particular variation of a "free" license that an author
might choose. From the various objections I have read about the AGPL,
however, there seem to be a number of people who do not share its
goals. But I do not recall reading any statement of objections that
concluded it was not a "free" license or that set forth any realistic
example of impracticability. I could be persuaded; I just haven't seen
any substance so far. (I'm just a bystander, of course, so you need not
think you've won or lost anything by my opinion.)
Here's what I think needs to be addressed if anyone wants to make
actual progress on this subject:
- What exactly is it that someone wants to do that they are prevented
from doing by the terms of the AGPL?
- What other license would be required to allow them to implement a
derived work, offer it to public users, and refuse to share their
changes? (I'm aware that's a loaded phrasing, but that is the
hypothetical problem as seen by those who choose this license.)
- Is this discussion really about nothing more than what
"distribution" means in the context of a public-facing server-based
application?
Greg Harris
Miriam Ruiz
> I do not profess any expertise or experience with Debian policies other
> than a general reading. Nor do I think of myself as a defender or
> critic of any particular variation of a "free" license that an author
> might choose. From the various objections I have read about the AGPL,
> however, there seem to be a number of people who do not share its
> goals. But I do not recall reading any statement of objections that
> concluded it was not a "free" license or that set forth any realistic
> example of impracticability. I could be persuaded; I just haven't seen
> any substance so far. (I'm just a bystander, of course, so you need not
> think you've won or lost anything by my opinion.)
I don't want to light that flame again, as there is nothing new about
it since last time we discussed it, so I personally have nothing to
add to what I said in previous threads and I just don't like to move
in circles discussing the same things all over again. I'm just writing
to confirm that there are some of us who don't consider AGPL as free
(even though I acknowledge that Debian as an organization does, for
the moment), and that in the last threads there have been some
scenarios described that where problematic. The consensus you seem to
describe does not exist.
Greetings,
Miry
Bill Allombert
> On Mon, 23 Mar 2009 14:27:42 +0100
> Bill Allombert <Bill.Al...@math.u-bordeaux1.fr> wrote:
>
> > Hello Debian legal,
>
> during my short time subscribed to this list. If you are interested in
> actual comments, you may want to review the previous discussions. If
> you are interested in renewed (and to my mind unproductive) bouts of
> rehashing these questions, no doubt you will get that result as well.
Good.
> From a purely personal perspective, I just don't see the problem.
> Authors who choose to license their work under the AGPL have a desire
> not to see derivative works locked up inside a walled garden under some
> pretense that those derivative works are not "distributed" when they
> are offered for public user interaction. There is nothing in that goal
> that is in any way incompatible with the goals of the GPL. (As you
> quote: "Rules that require release of source code to the users for
> versions that you put into public use are also acceptable.")
But "public use" is not defined.
> With respect to your identified problems, Alice would have been under
> an obligation to provide source code for her derived version to Bill.
> When Bill distributes (and that, really, is what we are talking about
> here) a modified derivative version to public users, Bill undertakes an
> obligation to make available the source code to those users. I do not
> see anywhere a basis to invent any ongoing obligation for Alice.
I cannot see how you can reach that conclusion. To quote the text:
Notwithstanding any other provision of this License, if you modify
the Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your
version supports such interaction) an opportunity to receive the
Corresponding Source of your version
Alice modified the program, not Bill, so the word "you" can only mean Alice.
This paragraph does not even mention the word "distribution".
> Similarly, if the AGPL does not specify that modified source code must
> be made available from the same or a different network, that
> emphatically is not a shortcoming. It can be either, or both, but not
> none.
>
> Your items (2) and (4) are, frankly, mystifying. If those are
> intended to represent actual concerns, you have not explained them
> in a way that I can understand. (Your fifth issue leads me to suspect
> that none of them are concrete problems. Does a mere recompiling alter
> the source code? How does this raise any issue concerning the AGPL that
> does not also effect other licenses?)
All other free software license I know may restrict redistribution of modified
or unmodified version but never plain modification.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
MJ Ray
> Here's what I think needs to be addressed if anyone wants to make
> actual progress on this subject:
>
> - What exactly is it that someone wants to do that they are prevented
> from doing by the terms of the AGPL?
Use it on their website without being liable for the cost of download
for code that they have not written or modified.
This is the flip-side of the freedom to distribute when you wish and
the AGPL problem is a consequence of the confusion over whether you
are compelled to distribute the whole thing or only your changes.
Also, whether that distribution must be to everyone who has any sort
of access to it, only to users who are allowed to log in (or similar),
or only "when you wish" (which is a phrase RMS used to use when
explaining the four freedoms - I wonder if he still does).
> - What other license would be required to allow them to implement a
> derived work, offer it to public users, and refuse to share their
> changes? (I'm aware that's a loaded phrasing, but that is the
> hypothetical problem as seen by those who choose this license.)
It's not only a loaded phrasing, but I don't understand it. Surely
it's not suggesting that we're only objecting to the AGPL because it's
the AGPL and not some other licence? That's not it at all.
> - Is this discussion really about nothing more than what
> "distribution" means in the context of a public-facing server-based
> application?
Mostly but not exactly: I think it's also about who is a user in the
context of a private server-based application on a public-visible
server.
Hope that explains,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Greg Harris
MJ Ray <m...@phonecoop.coop> wrote:
This is helpful. Thanks. More in-line.
> Greg Harris <glha...@panix.com> wrote: [...]
> > Here's what I think needs to be addressed if anyone wants to make
> > actual progress on this subject:
> >
> > - What exactly is it that someone wants to do that they are
> > prevented from doing by the terms of the AGPL?
>
> Use it on their website without being liable for the cost of download
> for code that they have not written or modified.
"This site runs free-app plus X; here's where you can get it." If such
a notice is believed not to satisfy some interpretation of specific
language in the license, what needs to be changed in the license
language to resolve that concern? (It ought to be remembered that
contracts (including licenses) as a general rule are legally
interpreted with an implied term of reasonableness unless specific
language imposes a more rigorous obligation.)
>
> This is the flip-side of the freedom to distribute when you wish and
> the AGPL problem is a consequence of the confusion over whether you
> are compelled to distribute the whole thing or only your changes.
> Also, whether that distribution must be to everyone who has any sort
> of access to it, only to users who are allowed to log in (or similar),
> or only "when you wish" (which is a phrase RMS used to use when
> explaining the four freedoms - I wonder if he still does).
>
> > - What other license would be required to allow them to implement a
> > derived work, offer it to public users, and refuse to share their
> > changes? (I'm aware that's a loaded phrasing, but that is the
> > hypothetical problem as seen by those who choose this license.)
>
> It's not only a loaded phrasing, but I don't understand it. Surely
> it's not suggesting that we're only objecting to the AGPL because it's
> the AGPL and not some other licence? That's not it at all.
I was unintentionally obscure. I'm making an assumption that the AGPL
is intended to address the following type of hypothetical situation.
Developer A releases an interesting cloud application with future
potential. Choose-your-random-malicious-corporate-bad-actor Z adds some
nifty widgets to the free application and runs it on its servers for
hefty subscription fees. Z withholds the source code for its
modifications; A is not happy. Because A foresees this possible
outcome, he or she wants to prevent it by appropriate licensing terms.
How that gets accomplished is always susceptible to improvement and
suggestions. If developer A has a valid interest in seeking to preserve
free availability of the source for derived works, there ought to be
some way to accomplish that. And a license that does this, and no more,
ought not to be characterized as non-free.
Now, that leaves open the question of whether the AGPL does "more" in
some unacceptable way. This is where, at least in my opinion,
productive discussion would occur.
>
> > - Is this discussion really about nothing more than what
> > "distribution" means in the context of a public-facing
> > server-based application?
>
> Mostly but not exactly: I think it's also about who is a user in the
> context of a private server-based application on a public-visible
> server.
As a working first approximation, it seemed to me that this is exactly
where developer A's concerns get triggered: offering the
derivative application to public users but withholding the source. At
the core, if the application offers no functionality to the operator of
the server without those public users, that's where developer A wants
to see derivative-work source code made available.
Arguments that start from the premise that the derived work is running
only on "my" machine and that therefore no other concerns are
implicated miss the mark, in my opinion. At least they are unlikely to
persuade developer A to change his or her position.
>
> Hope that explains,
It helps.
Ben Finney
> (It ought to be remembered that contracts (including licenses) …
Whoa. Since when is a copyright license considered a contract?
Contracts require multipartite negotiation; I can't negotiate the
terms of a software license in most cases.
Free-software licenses especially are (by definition) unilateral
grants of permission, so I can't see how you lump them under contract.
--
\ “I got fired from my job the other day. They said my |
`\ personality was weird. … That's okay, I have four more.” |
_o__) —Bug-Eyed Earl, _Red Meat_ |
Ben Finney
Greg Harris
Ben Finney <ben+d...@benfinney.id.au> wrote:
> Greg Harris <glha...@panix.com> writes:
>
> > (It ought to be remembered that contracts (including licenses) …
>
> Whoa. Since when is a copyright license considered a contract?
> Contracts require multipartite negotiation; I can't negotiate the
> terms of a software license in most cases.
>
> Free-software licenses especially are (by definition) unilateral
> grants of permission, so I can't see how you lump them under contract.
>
Um, no. Software licenses are one instance of a class of unilateral
contracts. Another instance is product warranties. Yet another class is
a store's advertised prices for goods. There are others.
In (somewhat) formal terms, the offeror proposes terms that the offeree
may accept through some act of performance. Negotiation is not
required. The parties need not engage in any communication at all. If
you deposit the requisite coinage into a vending machine and a beverage
is not delivered, the vendor has breached a contract with you. The
warranty for your television is a contract. So are software licenses.
In various disputes about shrink-wrapped EULAs, one of the issues was
whether the consumer could have "accepted" the terms of the agreement
without those terms being available before purchase of the box. At the
other end of the spectrum, there are software licenses that are heavily
negotiated and involve substantial monetary terms.
Writing a bit of CSS and designing a kernel filesystem may be more
different in some ways than they are alike, but at some level of useful
abstraction they are both instances of coding and share certain
fundamental attributes. Reality has a way of jostling our
preconceptions.
Cheers.
Sean Kellogg
> On Wed, 25 Mar 2009 09:51:14 +1100
> Ben Finney <ben+d...@benfinney.id.au> wrote:
>
> > Greg Harris <glha...@panix.com> writes:
> >
> > > (It ought to be remembered that contracts (including licenses) …
> >
> > Whoa. Since when is a copyright license considered a contract?
> > Contracts require multipartite negotiation; I can't negotiate the
> > terms of a software license in most cases.
> >
> > Free-software licenses especially are (by definition) unilateral
> > grants of permission, so I can't see how you lump them under contract.
> >
>
> Um, no. Software licenses are one instance of a class of unilateral
> contracts. Another instance is product warranties. Yet another class is
> a store's advertised prices for goods. There are others.
>
> In (somewhat) formal terms, the offeror proposes terms that the offeree
> may accept through some act of performance. Negotiation is not
> required. The parties need not engage in any communication at all. If
> you deposit the requisite coinage into a vending machine and a beverage
> is not delivered, the vendor has breached a contract with you. The
> warranty for your television is a contract. So are software licenses.
>
> In various disputes about shrink-wrapped EULAs, one of the issues was
> whether the consumer could have "accepted" the terms of the agreement
> without those terms being available before purchase of the box. At the
> other end of the spectrum, there are software licenses that are heavily
> negotiated and involve substantial monetary terms.
Mr. Harris here is correct, for *most* cases. There does exist, however, a hypothetical license which is NOT a contract... though you don't see them very often. This is where person A gives something to person B without any expectation from person B. This is a unilateral grant of permission and would not be enforceable as a contract for lack of consideration. However, the license is still good until such time as A withdraws the grant, which he could conceivably do at any time. It's no different than if I invite you into my house, which the court sees as a license to enter my property, converting the person from trespasser to invitee.... but I can kick that person out whenever I like. The moment we sign a lease (another form of contract) I lose that power because the contract grants the leasor the right to be on the premises and is enforceable (assuming I got something in the lease, like rent money).
In case anyone is wondering, the general point of view of law professor who write articles about such things is that the GPL *is* a contract, because it requires the recipient to forbear certain warranty rights.
-Sean
--
Sean Kellogg
e: skel...@gmail.com
Miriam Ruiz
> On Tuesday 24 March 2009 05:22:34 pm Greg Harris wrote:
>> > Free-software licenses especially are (by definition) unilateral
>> > grants of permission, so I can't see how you lump them under contract.
>>
>> Um, no. Software licenses are one instance of a class of unilateral
>> contracts. Another instance is product warranties. Yet another class is
>> a store's advertised prices for goods. There are others.
>
> In case anyone is wondering, the general point of view of law professor who write articles about such things is that the GPL *is* a contract, because it requires the recipient to forbear certain warranty rights.
All that is for USA, right? Do you know whether it works that way in
other countries than USA, and probably UK, Canada and Australia too?
Greetings,
Miry
Sean Kellogg
Pretty much everything I stated above is from common law and predates the formation of the United States. It's probably a safe bet that it applies to any political entity that was under British rule at one time or another. Having said that, it is also codified in the Uniform Commercial Code, which is a U.S. produced set of "best practices" law which are heavily influential in any part of the world that wants to do business with the United States. I have no doubt that there are many jurisdictions that don't follow the UCC -- or anything close to it -- but my understanding is the global legal community is fairly uniform on naming conventions like these. It's the implication of the UCC that jurisdictions tend to diverge (even between individual U.S. states you see lots of variation in how the UCC is implemented).
But I'm not an expert on international law, much less the national laws of any other country.
-Sean
--
Sean Kellogg
e: skel...@gmail.com
Greg Harris
Exactly right. You might sometimes run across court decisions that
distinguish a contract from a "mere license" based on the absence of
"consideration" (which typically involves a payment of money, but may
take other forms).
Another arcane (but completely useless) example occurs to me: if M
revokes 007's license to kill, Bond does not have a claim for breach of
contract.
>
> In case anyone is wondering, the general point of view of law
> professor who write articles about such things is that the GPL *is* a
> contract, because it requires the recipient to forbear certain
> warranty rights.
>
> -Sean
>
--
Greg Harris
The broad point about "what is a contract" applies to jurisdictions
based on the English common law development and is not likely to differ
in material application in jurisdictions with a civil code history.
Statutory differences may crop up here and there (among states within
the US there may be technical differences about shrinkwrap EULAs).
The more important point is that when a court must determine the
meaning of language in a software license it will use the same tools
and reasoning that it applies to contracts generally.
MJ Ray
> > > prevented from doing by the terms of the AGPL?
> >
> > Use it on their website without being liable for the cost of download
> > for code that they have not written or modified.
>
> "This site runs free-app plus X; here's where you can get it." If such
> a notice is believed not to satisfy some interpretation of specific
> language in the license, what needs to be changed in the license
> language to resolve that concern? (It ought to be remembered that
> contracts (including licenses) as a general rule are legally
> interpreted with an implied term of reasonableness unless specific
> language imposes a more rigorous obligation.)
I think the simplest thing is to explicitly permit some or all of the
Corresponding Source being made available from a publicly accessible
network server as part or full (respectively) satisfaction of the
requirement. This was the gist of comment 3501 in the AGPLv3 drafting
process and - like many submissions to that process <rant>by the
people who were running the right software to be allowed in</rant> -
appears to remain unresolved.
http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-3&id=3501
If there is some justification for pointing to a publicly accessible
network server and not having to check its availability as being
allowed as a consequence of the general implied term of
reasonableness, then I'd welcome an explanation of why. IANAL.
This leaves one troublesome subcase, of private use on a public
network server, which might be fixed by narrowing which users have the
right to download the Corresponding Source.
[...]
> I was unintentionally obscure. I'm making an assumption that the AGPL
> is intended to address the following type of hypothetical situation.
> Developer A releases an interesting cloud application with future
> potential. Choose-your-random-malicious-corporate-bad-actor Z adds some
> nifty widgets to the free application and runs it on its servers for
> hefty subscription fees. Z withholds the source code for its
> modifications; A is not happy. Because A foresees this possible
> outcome, he or she wants to prevent it by appropriate licensing terms.
Here the scenario becomes impossible IMO - if Z is truly a bad actor,
Z will always either find a way to withhold their source code or
develop on an alternative A's application. AGPL may hinder Z, but
would not prevent it. I hesitate to highlight the loopholes, but I
think they've been posted here before.
I feel that the question is: how much is A willing to cost good users
in order to hinder bad actors like Z? How much should one limit
freedom in the name of freedom? Why should A be supported in trying
to do the impossible?
This is a problem I'd met in other contexts in the past.
http://mjr.towers.org.uk/writing/fightingshadows.html
is pretty much where I got with it.
[...]
> > > - Is this discussion really about nothing more than what
> > > "distribution" means in the context of a public-facing
> > > server-based application?
> >
> > Mostly but not exactly: I think it's also about who is a user in the
> > context of a private server-based application on a public-visible
> > server.
>
> As a working first approximation, it seemed to me that this is exactly
> where developer A's concerns get triggered: offering the
> derivative application to public users but withholding the source.
In the context I'm trying to highlight, the derivative application is
only visible to the public so that they can request access - it is not
doing any significant work for them beyond that. Does that clarify
this part of the discussion?
Hope that helps,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
MJ Ray
> Ben Finney <ben+d...@benfinney.id.au> wrote: [...]
> > Free-software licenses especially are (by definition) unilateral
> > grants of permission, so I can't see how you lump them under contract.
>
> Um, no. Software licenses are one instance of a class of unilateral
> contracts. Another instance is product warranties. Yet another class is
> a store's advertised prices for goods. There are others.
This is an old chestnut and there are several points of view with no
internationally-accepted conclusion as far as I can tell. Here's four
of the previous subthreads at random:-
http://lists.debian.org/debian-legal/2003/09/msg00084.html
http://lists.debian.org/debian-legal/2005/05/msg00453.html
http://lists.debian.org/debian-legal/2004/06/msg00275.html
http://lists.debian.org/debian-legal/2004/12/msg00220.html
Fortunately, I thought it doesn't really matter in this case because
judges in copyright cases applied some rule of reasonableness (even if
it sometimes seems incomprehensible), so I let it slide.
Can we not examine the chestnut in detail right here, please?
Thanks,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Ian Jackson
well consider using the AGPL for works of my own. I don't have time
now to write a detailed rebuttal to each of Bill's points, I'm afraid.
Ian.
Wesley J. Landaker
> Here the scenario becomes impossible IMO - if Z is truly a bad actor,
> Z will always either find a way to withhold their source code or
> develop on an alternative A's application. AGPL may hinder Z, but
> would not prevent it. I hesitate to highlight the loopholes, but I
> think they've been posted here before.
I'm for full-disclosure of loopholes. I've posted about one before:
http://lists.debian.org/debian-legal/2007/12/msg00061.html
The kernel is: "... ironically, if there is an AGPLv3 work that already has
the give-remote-users-source-code feature and I'm making modifications to
the work, I'm obligated to keep that feature there, unless I remove it."
There are other weaknesses ripe for exploitation by someone who really
doesn't want to follow the "spirit" of the license. This is true of most
licenses, including the GPL (even v3), but I think the AGPL is particularly
weak (at least the "A" part is).
--
Wesley J. Landaker <w...@icecavern.net> <xmpp:w...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Bill Allombert
> On Tuesday 24 March 2009 20:32:10 MJ Ray wrote:
> > Here the scenario becomes impossible IMO - if Z is truly a bad actor,
> > Z will always either find a way to withhold their source code or
> > develop on an alternative A's application. AGPL may hinder Z, but
> > would not prevent it. I hesitate to highlight the loopholes, but I
> > think they've been posted here before.
>
> I'm for full-disclosure of loopholes. I've posted about one before:
> http://lists.debian.org/debian-legal/2007/12/msg00061.html
>
> The kernel is: "... ironically, if there is an AGPLv3 work that already has
> the give-remote-users-source-code feature and I'm making modifications to
> the work, I'm obligated to keep that feature there, unless I remove it."
I read your email and I think you are partially mistaken:
Copyright law in most juridiction restrict plain modification of
softwares, even without further copy and/or redistribution
(outside modifications that fall under fair-use or equivalent limitations),
so you have to accept the license to have the right to modify the software
in the first place, even if you do not distribute it.
Cheers,
--
Bill. <ball...@debian.org> (please CC me)
Imagine a large red swirl here.
Francesco Poli
[...]
> 0) Conflict with the The Free Software Definition:
> <http://www.gnu.org/philosophy/free-sw.html>
>
> The AGPL is in direct conflicts with the two paragraphs below:
I don't think the AGPLv3 actually is in conflict with what the FSF
*now* states among their "explanations" and "clarifications" of the FSD.
Included in the paragraphs you quoted, there's the following sentence:
[...]
> Rules that require release of
> source code to the users for versions that you put into public use are
> also acceptable.
[...]
Let's look better, though: has this sentence always been in the
explanations of the FSD?
The answer is: no, it hasn't.
It seems [1] that this sentence was added on June 19th, 2005.
No surprise: the FSF was preparing the propaganda to make us think that
the AGPLv3 is an acceptable license for Free Software... by adjusting
the interpretation of the Free Software Definition!
For the record, I personally think that the GNU AfferoGPL v3 does *not*
meet the DFSG: my analysis [2] was sent to this list long ago.
[1] http://web.cvs.savannah.gnu.org/viewvc/www/philosophy/free-sw.html?root=www&r1=1.38&r2=1.39
[2] http://lists.debian.org/debian-legal/2007/11/msg00233.html
--
New location for my website! Update your bookmarks!
http://www.inventati.org/frx
..................................................... Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Bill Allombert
> I don't think there are any problems with the AGPL and indeed I might
> well consider using the AGPL for works of my own. I don't have time
That is not very interesting, because if you are the sole copyright holder, you
do not have to comply with the term of the AGPL and I can see how restricting
what others can do with your code could be an advantage to you.
> now to write a detailed rebuttal to each of Bill's points, I'm afraid.
Would you settle for a non-detailed rebuttal limited to the technical points ?
So far the only rebuttals I have seen involve a free-as-in-beer third-party
VCS hosting service, which does not address my issues (mainly, that it put
obligation on the person which has modified the software long after they
stopped using it and distributing it).
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Florian Weimer
> All that is for USA, right? Do you know whether it works that way in
> other countries than USA, and probably UK, Canada and Australia too?
There is no such thing as a unilateral contract in Germany. Over
here, free software licenses are typically considered invitations to
enter licensing contracts, according to the terms in those licenses.
The net effect is still the same, I think. If you reject the offer,
you haven't got a license.
Steve Langasek
> > All that is for USA, right? Do you know whether it works that way in
> > other countries than USA, and probably UK, Canada and Australia too?
> There is no such thing as a unilateral contract in Germany.
There's no such thing as a unilateral contract anywhere else either. A
license is not a contract.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Chris Harshman
> On Sat, Aug 22, 2009 at 02:31:38PM +0200, Florian Weimer wrote:
>
> > > All that is for USA, right? Do you know whether it works that way in
> > > other countries than USA, and probably UK, Canada and Australia too?
>
> > There is no such thing as a unilateral contract in Germany.
>
> There's no such thing as a unilateral contract anywhere else either. A
> license is not a contract.
There's an excellent discussion on the finer points of this distinction
(albeit under U.S. law) in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir.
2008). I have the opinion if anyone wants to read it (not sure how
accessible it is outside a legal research database subscription).
Ben Finney
> * Miriam Ruiz:
>
> > All that is for USA, right? Do you know whether it works that way in
> > other countries than USA, and probably UK, Canada and Australia too?
>
> There is no such thing as a unilateral contract in Germany.
Nor anywhere, AFAIK. The idea is not to enter a contract, but to
unilaterally grant permissions otherwise reserved. The common meaning of
“license” essentially means “permission”, after all.
> Over here, free software licenses are typically considered invitations
> to enter licensing contracts, according to the terms in those
> licenses.
That's a shame, since that's counter to (my unserstanding of) the
intention: to unilaterally grant license to someone who would not
otherwise have it.
> The net effect is still the same, I think. If you reject the offer,
> you haven't got a license.
No, that's not the case for a unilateral grant of license. There's no
offer being made, and therefore no agreement to be entered into; the
recipient doesn't have to agree to do anything to have the specific
permissions granted by the license terms.
However, any actions *not* licensed are outside the grant, and are
covered by relevant law.
--
\ “It is well to remember that the entire universe, with one |
`\ trifling exception, is composed of others.” —John Andrew Holmes |
_o__) |
Ben Finney
Greg Harris
Chris Harshman <r...@packetlaw.com> wrote:
> On Sat, 2009-08-22 at 12:43 -0700, Steve Langasek wrote:
> > On Sat, Aug 22, 2009 at 02:31:38PM +0200, Florian Weimer wrote:
> >
> > > > All that is for USA, right? Do you know whether it works that
> > > > way in other countries than USA, and probably UK, Canada and
> > > > Australia too?
> >
> > > There is no such thing as a unilateral contract in Germany.
> >
> > There's no such thing as a unilateral contract anywhere else
> > either. A license is not a contract.
>
> There's an excellent discussion on the finer points of this
> distinction (albeit under U.S. law) in Jacobsen v. Katzer, 535 F.3d
> 1373 (Fed. Cir. 2008). I have the opinion if anyone wants to read it
> (not sure how accessible it is outside a legal research database
> subscription).
>
>
>
>
The full opinion can be found at either of these:
http://www.altlaw.org/v1/cases/1667254
http://www.cafc.uscourts.gov/opinions/08-1001.pdf
JMRI has a summary of their case and collect many of the related
documents at http://jmri.sourceforge.net/k/index.html.
The arguments and conclusions are quite technical. (Is the license term
a condition that restricts the scope of what was granted or a covenant
that was a more general term of the contract?) A crucial (and barely
explained) starting point for the legal analysis is that software
licenses are a variety of contracts and are governed by principles of
contract law. (Jacobsen's lawyer argued, as one alternative, that no
contract had been formed,
http://jmri.sourceforge.net/k/docket/cafc-pi-1/AppellantsBrief.pdf, a
conclusion the court did not accept.) The important thing about the
decision was that the court found Jacobsen could pursue a _remedy_ for
the breach of the license both under general contract law and under
copyright law. Copyright law gives licensors certain remedies in
addition to those they would have under general contract law.
Sean Kellogg
> On Sat, 22 Aug 2009 14:17:49 -0700
> Chris Harshman <r...@packetlaw.com> wrote:
>
> > On Sat, 2009-08-22 at 12:43 -0700, Steve Langasek wrote:
> > > On Sat, Aug 22, 2009 at 02:31:38PM +0200, Florian Weimer wrote:
> > >
> > > > > All that is for USA, right? Do you know whether it works that
> > > > > way in other countries than USA, and probably UK, Canada and
> > > > > Australia too?
> > >
> > > > There is no such thing as a unilateral contract in Germany.
> > >
> > > There's no such thing as a unilateral contract anywhere else
> > > either. A license is not a contract.
> >
> > There's an excellent discussion on the finer points of this
> > distinction (albeit under U.S. law) in Jacobsen v. Katzer, 535 F.3d
> > 1373 (Fed. Cir. 2008). I have the opinion if anyone wants to read it
> > (not sure how accessible it is outside a legal research database
> > subscription).
In the interest of warning folks who might stumble upon this thread and look to this case law as controlling in the United States, please note that the court in question is the Federal Circuit. The Federal Circuit has jurisdiction over patent cases (and a number of other issues that the government has decided needs consistency across the nation). It does not have primary jurisdiction over copyright cases and only touches on the subject in the situation where a patent issue is the primary focus and the copyright issue is of secondary concern.
I mention this because the Federal Circuit has a very bad track record when it comes to applying copyright law, and the other circuits seem to avoid citing the Fed Circuits decisions in this area. The problem, ultimately, is you have a bunch of judges who live in the world of "idea protection" and want to apply that same way of thinking to "expression protection", when the two are fundamentally different under US law. Too much stuffing round pegs into square holes.
This is to say nothing of the significant overturn rate of the Fed Circuit on matters of /patent/ law by the Supreme Court, which suggests the Fed Circuit's legal isolation has allowed it to veer far out of the legal mainstream.
Anyway, whatever you glean out of the case law, just remember that if you do end up in a US court over a copyright issue, chances are you going to be in one of the regional circuits where the Fed Circuit. case law on this are is suspect at best.
-Sean
--
Sean Kellogg
e: skel...@probonogeek.org
w: http://blog.probonogeek.org