Re: Alternatives to the Affero General Public License

[Gregor Richards]

On Tue, 21 Jun 2005 23:57:39 -0700, "Gregor Richards"
<[EMAIL PROTECTED]> said:
> Jacobo Tarrio wrote:
> 
> >O Martes, 21 de Xuño de 2005 ás 20:07:36 -0700, Gregor Richards escribía:
> >
> >>In response section 6:
> >>(So that I can reference, the full section:)
> >>6.  Each time you redistribute the Program (or any work based on the
> >>Program), the recipient automatically receives a license from the
> >>original licensor to copy, distribute or modify the Program subject to
> >>these terms and conditions. You may not impose any further restrictions
> >>on the recipients' exercise of the rights granted herein. You are not
> >>responsible for enforcing compliance by third parties to this License.
> >>  It seems to me that the license from the original licensor would
> >>  include this new term/condition, as that is how (s)he licensed it. 
> >
> >
> > If you look closely, it says "subject to these terms and conditions" and
> >"the rights granted herein", not "subject to the same terms and conditions
> >under which you received the Program" nor "the rights granted to you".
> >
> >>  I of course can't make an entirely new license based on the GNU GPL
> >>  without FSF's permission, so is there any way that a term could be added
> >>  at all?
> >
> >
> > You can, if you remove the preamble.
> >
> > http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL
> >
> >>In response to the dissident problem:
> >>I don't see how this hinders said dissident at all.  If said dissident
> >>has to send the entire source, (s)he as already made it available
> >>through some computer network.
> >
> >
> > Made *what* available? An interface to the program, not the program itself,
> >like in the GPL.
> >
> >> If said dissident made it available on a public computer network, they
> >>have already incriminated themselves
> >
> >
> > Not necessarily. For example, in a CMS for dissidents, the source code
> >might include "workflow" code that reflects the structure of the dissident
> >organization (for example, the text is written then sent for approval to the
> >local coordinator, then to the regional coordinator, then it is published
> >and a copy is sent to the pamphlet printers). The source code now contains
> >information which is not present in the user interface but is incriminating.
> >
> In response to "You can, if you remove the preamble"
> Yes, I realized that just a bit too late, but have now made a hybrid
> license.  The FAQ doesn't make it clear whether you should maintain the
> FSF Copyright ... on the one hand, the FAQ seems pretty insistant that
> you remove all reference to GNU or FSF, but on the other hand, it's
> certainly still copyrighted by the FSF.  :(
> 
> In response to "An interface to the program, not the program itself"
> Am I the only person who fails to see this as a significant difference? 
> I don't think the freedoms of Free Software should be limited to people
> who actually have copies of the software, but to all users of the
> software.
> 
> In response to the dissident problem:
> I see putting it on a public network as equivilant to uploading a binary
> of a GPL'd program to www.illegal-dissident-files.com .  If they do that
> as a handy means of distribution, they have to provide the sources.  So
> what do they do?  They don't put it on a public server.  This is not
> discrimination against these dissidents, because they are not required
> to put it on a public server.  Well, my proposed modified license also
> does not require that they put it on a public server.  Even if they do
> put it on a public server, they can put it behind a .htpasswd file. 
> Users who are blocked by the .htpasswd file never interact with the
> program, and hence the code does not need to be sent.
> Realistically, to most users, and even to most programmers most of the
> time, a binary is just a black hole that produces output.  Source is
> what makes it less than just a black hole.  I don't see why the right to
> read the code behind this black hole of functionality should be limited
> only to binaries physically on a system, and not to programs running
> over a network.
> And I think there's too much weight being placed on the distinction
> between having a binary on one's system and running it through other
> means.
> Just my opinion though *shrugs*
> 
>  - Gregor Richards
> -- 
>   Gregor Richards
>   [EMAIL PROTECTED]
> 
> -- 
> http://www.fastmail.fm - A fast, anti-spam email service.
> 

Err, sorry, let me briefly correct myself here...
> I see putting it on a public network as equivilant to uploading a binary
> of a GPL'd program to www.illegal-dissident-files.com .  If they do that
> as a handy means of distribution, they have to provide the sources.
They have to provide the sources ... or a written offer for them, to
anyone who actually downloads the binary, etc, etc.  But the basic point
is still valid.
-- 
  Gregor Richards
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

Re: quake2 and german youth protection law

[Michael Below]

Michael Below <[EMAIL PROTECTED]> writes:

> As a next step, I think we should tell the german mirror ftp admin
> about our conclusions, if we agree on the legal matters.

Hm. Nobody seems to disagree, right? I will inform the german mirror
admin tomorrow.

Michael Below


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug #309257: libpano12: patent problems

[Adrian von Bidder]

On Wednesday 22 June 2005 03.25, Florent Bayle wrote:
[libpano12]
> http://www.virtualproperties.com/noipix/patents.html suggests that there
> is clear prior art in this case. I have taken this link from previous
> discution on debian-legal. But Robert Jordens thinks that :
> "The prior art argument is pretty much irrelevant in our question as long
> as the legal status quo is different and the patent has not been
> challanged."

Wouldn't this be a case where pubpat could be asked to review the patent and 
try to challenge it?  Debian is, after all, quite well-known, and if this 
patent really
 - has prior art and thus should be available, and
 - is enforced aggressively enough that some developers have been scared 
away,
I think pubpat might be interested.

(The two items above were hinted at in this discussion - I'm not familiar 
with the case, just jumping in.)

cheers
-- vbi

-- 
Compatible: Gracefully accepts erroneous data from any source.


pgpi3Sxks3RG0.pgp
Description: PGP signature

Re: Alternatives to the Affero General Public License

[Lewis Jardine]

Gregor Richards wrote:

In response section 6:
(So that I can reference, the full section:)
6.  Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further restrictions
on the recipients' exercise of the rights granted herein. You are not
responsible for enforcing compliance by third parties to this License.
  It seems to me that the license from the original licensor would
  include this new term/condition, as that is how (s)he licensed it. 
  Perhaps a rephrase as "an additional term" or something that made it

  obvious that this was a part of the license of the program and hence
  is not an additional restriction when redistributed?  I of course
  can't make an entirely new license based on the GNU GPL without FSF's
  permission, so is there any way that a term could be added at all?


Yes, the term reads 'You may not impose any further /restrictions/ on 
the recipients' exercise of the rights granted herein.', so you can add 
a term that grants the recipients more rights. You can't, however, take 
any rights granted by the unmodified GPL away (unless you re-write the 
licence, chop the preamble, and call it something else).


http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs - an 
example of adding a term that grants the recipient additional rights.

--
Lewis Jardine
IANAL, IANADD


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Humberto Massa Guimarães]

Hi Gregor. Let's see if I can understand your motivations, and help
you.

** Gregor Richards ::

> > In response to "An interface to the program, not the program
> > itself" Am I the only person who fails to see this as a
> > significant difference?  I don't think the freedoms of Free
> > Software should be limited to people who actually have copies of
> > the software, but to all users of the software.

You have to have in mind that when you copyleft something, you are
not only (potentially at least) augmenting the commons freedom, but
you are also diminishing the individual freedom of your licensees.

What do I mean? Well, if you license your software under the
MIT/BSD, you have given maximum freedom to your licensee, at the
potential cost to the commons freedom, because your licensee can
improve your software and make a proprietary version. If you license
your software under the GPL, you potentially augment the commons
freedom (because if someone improves your software, the improved
version will necessarily stay free -- or not be distributed at all)
at the cost of removing some freedom from your direct and indirect
licensees. What the DFSG does, IMHO, is to strike a balance between
minimum and maximum commons and licensees' freedoms.

What has not being pacified yet, even here in d-l, is exactly if
access to the interface of a program is equivalent -- in terms of
the balance between commons and licensees' freedoms --  to the
access to the program itself. And *that* is the opinion you seemed
to express with "am I the only person who fails to see this as a
significant difference?".

I, for one, see a very significant difference between having access
to the program itself and to its interface... Including, but not
restricted to, a hypotetical dissident organization for which access
to the program (even in binary form) can reveal details of the
organization to the Evil Government that simple, plain access to its
interface (even in a publicly accessed server) can hide those
issues.

Your argument seems to be that there is no additional onus in giving
to someone access to some program when you are giving this same
person access to the interface of said program. I disagree, altough
not strongly.

> > it less than just a black hole.  I don't see why the right to
> > read the code behind this black hole of functionality should be
> > limited only to binaries physically on a system, and not to
> > programs running over a network.  And I think there's too much
> > weight being placed on the distinction between having a binary
> > on one's system and running it through other means.  Just my
> > opinion though *shrugs*

This is an interesting point-of-view. In fact, I see why many
consider the "public performance" thing a loophole in the GPL.

I regard, IMHO, the GPL as being (de facto, not by a guideline) the
borderline "commons versus licensees" case of a Free Software
license.  Explaining: not many more-restrictive-than the GPL
licenses are considered DFSG-free; even the GPL, if the licensor
chooses to use its clause #8 (geographic distribution limitation),
for instance, can be considered non-DFSG-free; and finally, many of
the onerous-to-the-licensee exceptions in the GPL are, by design,
reflected in the DFSG.

This fact adds a difficulty when you try to give the commons an
additional potential freedom, by onerating the licensee when he is
not distributing, but only publically performing the work -- and you
still want to consider your work DFSG-free.

To clarify a little bit more on the "public performance" thing: if I
GPL a song and establish that its partiture is the source code, if
you record this song and send your .mp3 around, you must make the
partiture available. If I license the same song by your new license,
if you want to go to the nearest square and play it aloud in the
guitar, you must make the partiture available also.  That is the
difference between distribution and public performance, and that is
why I think there is an unacceptable additional onus to the licensee
in the latter case.

--
HTH,
Massa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug #309257: libpano12: patent problems

[Steve Langasek]

On Wed, Jun 22, 2005 at 03:25:22AM +0200, Florent Bayle wrote:
> Le Mercredi 22 Juin 2005 02:38, Steve Langasek a écrit :
> [...]
> > > You should not remove wontfix tag, it's maintainer role to decide if he
> > > will fix the bug or not.

> > The "wontfix" tag isn't really appropriate for an RC bug, however -- either
> > it gets fixed, or the package gets removed.

> Yes, but I think that this bug should not be RC (see below).

> [...]
> > > Please have a look at libjpeg62 (#153467) to see how such problem is
> > > treated.
> >
> > That bug shows people expressing the opinions that
> >
> > - we don't want to be hasty in removing software based on a patent before
> > we have reason to believe it's valid and may be enforced against us - we
> > consider the existence of prior art as sufficient reason to ignore the
> > patent, since legally, the patent is invalid
> >
> > both of these things are true, but you haven't really shown how either
> > relates to libpano12, AFAICT?

> http://www.virtualproperties.com/noipix/patents.html suggests that there is 
> clear prior art in this case. I have taken this link from previous discution 
> on debian-legal. But Robert Jordens thinks that :
> "The prior art argument is pretty much irrelevant in our question as long
> as the legal status quo is different and the patent has not been
> challanged."

> It's why I want to know what I have to do in this case (can we let this 
> software in Debian, even if the patent has not been challenged ?).

Well, if the prior art exists which shows the patent is invalid, I'm
personally satisfied that we can ship it, but this is actually the purview
of the ftp team to decide.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Alternatives to the Affero General Public License

[Gregor Richards]

On Tue, 21 Jun 2005 19:05:00 -0700, "Gregor Richards"
<[EMAIL PROTECTED]> said:
> Because the AGPL has some implementation issues that make it possibly
> incompatible with the DFSG, I've been trying to find an alternative that
> would still protect source-code redistribution on line.  Basically, I'm
> trying to write a special exception to the GNU GPL that would add this
> without some of the practical problems, and possibly with DFSG and OSI
> compliance.  I'm not entirely clear on to what extent point 4 (Integrity
> of The Author's Source Code) applies.  Clearly, the AGPL creates an
> "invariant section" like the GFDL, which doesn't work.  My proposed
> change works more like clause 2(c) of the GNU GPL.  There's no exact
> code that needs to be kept, but a certain functionality does.  I don't
> think this contradicts anything in the DFSG, but I'm no expert, and
> would like your opinions.
> 
> 
> 


I think I need to post my updated version, since it's had some minor
changes, plus an added section on temporary outages that I felt was
necessary (though it may just open up a new can of worms).
This would be an added clause 2(d) to the GNU GPL (forming a modified
license which is not, obviously, the GNU GPL)


If your work based on the Program is designed to interact with users
through a computer network, your work based on the Program must
prominently provide to all users who interact with it through a computer
network the opportunity to receive the complete source code for your
work based on the Program via that same network and the same protocol.
At your preference, or if that protocol lacks the means to send the
complete source code to the user, your work based on the Program may
instead use the HTTP protocol for this purpose. (Exception: if the
Program itself is designed to interact with users through a computer
network but does not normally provide this functionality, your work
based on the Program is not required to provide this functionality.)

* Your work based on the Program does not need to functionally
reproduce its own source code to fulfill this requirement. It may
instead send a prefabricated archive of the source code, if you
ensure that the program in the prefabricated archive is the same as
the program that will be interacted with through a computer network.
* You may optionally exclude in this transmission or archive any
files which serve only the purpose of configuring the Program, and
contain no program logic, so long as their complete function is
documented in the other files.
* You are not in violation of this license if a temporary (lasting
less than 24 hours), unpredictable (does not happen on a regular
basis or unusually often) situation beyond your control causes users
who interact with your copy of the Program or your copy of a work
based on the Program through a computer network to be unable to
receive the complete source code. If the situation lasts for more
than 24 hours, you must either disable interaction with the Program
through the affected computer network or by some means restore
source code transmission as described above.
-- 
  Gregor Richards
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
  unladen european swallow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: quake2 and german youth protection law

[MJ Ray]

Michael Below <[EMAIL PROTECTED]> wrote:
> Michael Below <[EMAIL PROTECTED]> writes:
> > As a next step, I think we should tell the german mirror ftp admin
> > about our conclusions, if we agree on the legal matters.
> 
> Hm. Nobody seems to disagree, right?

This was on the end of a very long email originally, so I don't
think you can tell much from lack of disagreement.  Disagree with
what, anyway? You have posted little about what you intend to
say. I suspect my conclusions are different to yours:

I am strongly against directing the German mirror admins about
such an unclear problem. If you want to send them a "this law
may be a problem" statement, fine, but maybe that should go
through debian-mirrors and/or debian-user-german.

It would probably be helpful to ask FFII's German branches
about this. My German isn't good enough to write that.
http://bb.ffii.org/ http://muenchen.ffii.org/

> I will inform the german mirror admin tomorrow.

There are around 25 mirrors in Germany that we know about.

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Mark Rafn]

Before going too far down this road, see
   http://lists.debian.org/debian-legal/2003/03/msg00805.html
for some fundamental questions about where to draw the line on this 
requirement.  Unless you're willing to say "all changes must be published, 
even if never released", it's gonna be tough to find a free way to require 
that any publication in the absence of distribution can be required.


On Tue, 21 Jun 2005, Gregor Richards wrote:


Because the AGPL has some implementation issues that make it possibly
incompatible with the DFSG


Just to be clear: I don't think that the AGPL's incompatibility with the 
freedom level guaranteed by the DFSG is an implementation issue.  It 
intenionally restricts my rights as a recipient/user/modifier more than 
something which claims to be free should do.  It's not an accident or 
problem with the wording, it's the pure reason the author didn't use the 
GPL in the first place.



I've been trying to find an alternative that
would still protect source-code redistribution on line.


I'm pretty sure you mean something other than "protect source-code 
redistribution".  "force redistribution of modified source" is closer.



trying to write a special exception to the GNU GPL that would add this
without some of the practical problems,


I'm afraid your task is impossible, as the problems are not "practical". 
They're due to the direct contradiction of what free software means.



If your work based on the Program is designed to interact with users
through a computer network


"designed to" is an interesting question.  What if it's not designed that 
way, but I make it do so via hackery or whatnot?


Also, "users" may give you trouble.  I write a lot of software that 
doesn't interact with users, but does interact with client programs that 
interact with hardware that interacts with users.


Am I a user of software in my ISP's routers?  Am I a user of their 
accounting system?  How about if it emails me statements?



your work based on the Program must
prominently provide to all users who interact with it through a computer
network the opportunity to receive the complete source code for your
work based on the Program via that same network and the same protocol.


Unworkable, but you give an out in the next section, so this clause will 
never be used.



At your preference, or if that protocol lacks the means to send the
complete source code to the user, your work based on the Program may
instead use the HTTP protocol for this purpose.


Still unworkable.  I want to use the code for some embedded use (say a 
bluetooth server in a mobile phone).  There's no room to implement an HTTP 
server in addition.  There's also no reason.


Even if there were, fine: I use HTTP to make the source available, but my 
firewall doesn't let that through.  The very fundamental problem you're 
facing is that you want to put a behavior restriction on the licensee (you 
must make source available in a reasonable way), but it cannot be done 
except as serious restrictions on the use of the software.



(Exception: if the
Program itself is designed to interact with users through a computer
network but does not normally provide this functionality, your work
based on the Program is not required to provide this functionality.)


Can I modify the program so that my version is "not designed" to interact 
with users through a computer network?  Can someone else then use the 
above exception to modify my version under the pure GPL?

--
Mark Rafn[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Gregor Richards]

On Wed, 22 Jun 2005 09:58:07 -0700 (PDT), "Mark Rafn" <[EMAIL PROTECTED]>
said:
> Before going too far down this road, see
> http://lists.debian.org/debian-legal/2003/03/msg00805.html
> for some fundamental questions about where to draw the line on this 
> requirement.  Unless you're willing to say "all changes must be
> published, 
> even if never released", it's gonna be tough to find a free way to
> require 
> that any publication in the absence of distribution can be required.
> 
> On Tue, 21 Jun 2005, Gregor Richards wrote:
> 
> > Because the AGPL has some implementation issues that make it possibly
> > incompatible with the DFSG
> 
> Just to be clear: I don't think that the AGPL's incompatibility with the 
> freedom level guaranteed by the DFSG is an implementation issue.  It 
> intenionally restricts my rights as a recipient/user/modifier more than 
> something which claims to be free should do.  It's not an accident or 
> problem with the wording, it's the pure reason the author didn't use the 
> GPL in the first place.
> 
> > I've been trying to find an alternative that
> > would still protect source-code redistribution on line.
> 
> I'm pretty sure you mean something other than "protect source-code 
> redistribution".  "force redistribution of modified source" is closer.
> 
> > trying to write a special exception to the GNU GPL that would add this
> > without some of the practical problems,
> 
> I'm afraid your task is impossible, as the problems are not "practical". 
> They're due to the direct contradiction of what free software means.
> 
> > If your work based on the Program is designed to interact with users
> > through a computer network
> 
> "designed to" is an interesting question.  What if it's not designed that 
> way, but I make it do so via hackery or whatnot?
> 
> Also, "users" may give you trouble.  I write a lot of software that 
> doesn't interact with users, but does interact with client programs that 
> interact with hardware that interacts with users.
> 
> Am I a user of software in my ISP's routers?  Am I a user of their 
> accounting system?  How about if it emails me statements?
> 
> > your work based on the Program must
> > prominently provide to all users who interact with it through a computer
> > network the opportunity to receive the complete source code for your
> > work based on the Program via that same network and the same protocol.
> 
> Unworkable, but you give an out in the next section, so this clause will 
> never be used.
> 
> > At your preference, or if that protocol lacks the means to send the
> > complete source code to the user, your work based on the Program may
> > instead use the HTTP protocol for this purpose.
> 
> Still unworkable.  I want to use the code for some embedded use (say a 
> bluetooth server in a mobile phone).  There's no room to implement an
> HTTP 
> server in addition.  There's also no reason.
> 
> Even if there were, fine: I use HTTP to make the source available, but my 
> firewall doesn't let that through.  The very fundamental problem you're 
> facing is that you want to put a behavior restriction on the licensee
> (you 
> must make source available in a reasonable way), but it cannot be done 
> except as serious restrictions on the use of the software.
> 
> > (Exception: if the
> > Program itself is designed to interact with users through a computer
> > network but does not normally provide this functionality, your work
> > based on the Program is not required to provide this functionality.)
> 
> Can I modify the program so that my version is "not designed" to interact 
> with users through a computer network?  Can someone else then use the 
> above exception to modify my version under the pure GPL?
> --
> Mark Rafn[EMAIL PROTECTED]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 


In response to "I'm afraid your task is impossible, as the problems are
not 'practical'. They're due to the direct contradiction of what free
software means."
The term "Free Software" is open to interpretation, the DFSG is not the
be-all-end-all of what is and isn't "Free".  After all, according to
www.gnu.org , the Affero General Public License is "Free Software," and
I should think that history would give them precedence in making such a
decision.  Just because it isn't "Free Software" in terms of the DFSG
doesn't mean that it can't be "Free Software" at all.


In response to "What if it's not designed that way, but I make it do so
via hackery or whatnot?"
Did that hackery modify the program's source code?  If so, it is now
designed to work via a computer network.  If not, well, I made no
attempt to close that loophole, that would add a huge amount of
complexity with little additional benefit.


In response to "Unworkable, but you give an out in the next section, so
this clause will never be used."
How is this unworkable?  Certainly many

Re: Alternatives to the Affero General Public License

[Gregor Richards]

On Wed, 22 Jun 2005 09:58:07 -0700 (PDT), "Mark Rafn" <[EMAIL PROTECTED]>
said:
> Before going too far down this road, see
> http://lists.debian.org/debian-legal/2003/03/msg00805.html
> for some fundamental questions about where to draw the line on this 
> requirement.  Unless you're willing to say "all changes must be
> published, 
> even if never released", it's gonna be tough to find a free way to
> require 
> that any publication in the absence of distribution can be required.
> 

Whoops, forgot to respond to that URL.

My opinion on it is that /use/ rather than /distribution/ is what should
be considered, so:
a-d should not require release of source, because Joe is the user of the
software, not the customer.

e is sort of on the line, but basically over it.  The customer is now
the user and should be allowed to get the source from Joe (on request).

f is back under the line, Joe is again the user of the software.

I'm unclear on g - if Joe starts up the program and puts in the input,
then that output is emailed automatically, Joe is still the user.  If it
actually grabs his email and such as an automated process, the customer
is now the user.

Same with f.  Does it get translated as part of the process, or does Joe
do it?

(Let me clarify my opinions on g and f.  The customer is the user
because the customer is interacting with the program - that is, the
actions of the customer are causing actions of the program.  In other
scenarios, the action of the customer does not cause action of the
program, because Joe may decide to be a jackass that day and spit in the
cusomer's face instead of running it through the program.  In those
scenarios, I would consider the customer to be a user of Joe-beta0.1.sh
rather than the typesetting software)

k and l are definitely over the line.  Now the customer is the user, and
should be able to see the code.

(All my opinions, of course).


By the way, as a response to having specific requirements for
distribution.  What if, rather than saying that the code must be
distributed via the same network medium, it said that the code must be
provided on request by any of the means allowed in the GPL (including
such strange means as snail-mail, etc).  Would that possibly push the
usability issue to the other side of the line?

 - Gregor Richards
-- 
  Gregor Richards
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - A fast, anti-spam email service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Mark Rafn]

I've trimmed a bunch of stuff, trying to leave only the real sticking 
points.  Basically, I believe the task requires restriction of use, not 
just distribution, and Debian should never accept it, so you may just want 
to ignore me if you think use restrictions are allowed.


Some things your license should clarify if you think this is necessary:

  1) What is a user?  Your response to the "Joe's Typesetting" mail is 
different from what many would assume you meant, and who knows what a 
court would decide you meant?


  2) What restrictions you place on recipients, as opposed to modifiers of 
code.  Say I modify and distribute code in accordance with your 
requirements, and I sell it to someone who runs it in a datacenter such 
that only the functional aspects are avaialble, and my mini-http server is 
blocked?  I've followed the license, but don't run a service.  They've 
followed the license (they haven't changed the software, so haven't 
broken any rules about what it must do), but don't make source available.


  3) Spend far more time on use cases and when source distribution is or 
is not required, rather than trying to come up with technical measures 
that are incomplete and probably obsolescent.


A few more line-by-line questions are below, but they're more comments 
than questions, and perhaps not productive to pursue further.


On Wed, 22 Jun 2005, Gregor Richards wrote:


The term "Free Software" is open to interpretation, the DFSG is not the
be-all-end-all of what is and isn't "Free".


True.  This is why I use and support Debian - it's the closest thing I can 
find to my personal definition of freedom.


After all, according to www.gnu.org , the Affero General Public License 
is "Free Software," and I should think that history would give them 
precedence in making such a decision.


Well, no.  debian-legal is the place that Debian discusses their 
definition.  Nobody has precedence in defining our terms.


If FSF acceptance is your goal, can you not just use the Affero license?


In response to "Unworkable, but you give an out in the next section, so
this clause will never be used."
How is this unworkable?  Certainly many, even most, protocols this would
apply to have this support.


I mean that it's a requirement that is obviously non-free as there are 
many applications for which it would be impossible.  It cannot be a 
requirement of free software.  In your example, it's not required, so it's 
not worth spending much time on.



In response to "Still unworkable.  I want to use the code for some
embedded use ..."
How is this unworkable?  To support the HTTP protocol to the degree of
sending source code does not require a full HTTP sever per se.  Hell,
you could just receive input and ignore it until a blank line, then send
Content-type: application/octet-stream





So if my code has such a thing, but no TCP/IP support so no way to 
actually connect to it, this is allowed?  Oh, and do bugs in my http 
implementation violate the license?



In response to "Can someone else then use the above exception to modify
my version under the pure GPL?"
Of course not.  Nobody ever said that it defaulted to the GNU GPL if
your modified version was non-networked.  This clause is still part of
the license, it just doesn't apply to you.  When you redistribute it to
the next person, if they make it web-based, they will have to make the
source available again.


Then I'm confused what the provision
  (Exception: if the Program itself is designed to interact with users
  through a computer network but does not normally provide this
  functionality, your work based on the Program is not required to provide
  this functionality.)
means.
--
Mark Rafn[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Humberto Massa Guimarães]

** Mark Rafn ::

> On Wed, 22 Jun 2005, Gregor Richards wrote:
> 
> > The term "Free Software" is open to interpretation, the DFSG is
> > not the be-all-end-all of what is and isn't "Free".
> 
> True.  This is why I use and support Debian - it's the closest
> thing I can find to my personal definition of freedom.
> 

Me too. And the process of discovering what is and what
is not DFSG-free is another thing that attracts me to Debian.

> > After all, according to www.gnu.org , the Affero General Public
> > License is "Free Software," and I should think that history
> > would give them precedence in making such a decision.
> 
> Well, no.  debian-legal is the place that Debian discusses their
> definition.  Nobody has precedence in defining our terms.
> 

Actually, the ftp-masters and other constituted Debian authorities
have precedence, and debian-legal is only their consulting body. But
the process and the discussions on d-l are a beautifully democratic
part of this process, and it's so good that actually the ftpmasters
often (always?) follow the d-l consensus.

> If FSF acceptance is your goal, can you not just use the Affero
> license?
> 
> > In response to "Unworkable, but you give an out in the next
> > section, so this clause will never be used." How is this
> > unworkable?  Certainly many, even most, protocols this would
> > apply to have this support.
> 
> I mean that it's a requirement that is obviously non-free as there
> are many applications for which it would be impossible.  It cannot
> be a requirement of free software.  In your example, it's not
> required, so it's not worth spending much time on.
> 

It would constitute unacceptable restrictions on the production of
derivative works, possibly combined with discrimination agains
fields of endeavour.

--
HTH,
Massa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Andrew Suffield]

On Wed, Jun 22, 2005 at 04:54:49PM -0300, Humberto Massa Guimar?es wrote:
> > > After all, according to www.gnu.org , the Affero General Public
> > > License is "Free Software," and I should think that history
> > > would give them precedence in making such a decision.
> > 
> > Well, no.  debian-legal is the place that Debian discusses their
> > definition.  Nobody has precedence in defining our terms.
> > 
> 
> Actually, the ftp-masters and other constituted Debian authorities
> have precedence, and debian-legal is only their consulting body. But
> the process and the discussions on d-l are a beautifully democratic
> part of this process, and it's so good that actually the ftpmasters
> often (always?) follow the d-l consensus.

There's nothing 'democratic' here. That means 'tyranny of the
masses'. Like most of Debian, we operate as an eclectic anarchy. Even
a minority viewpoint can win out if it happens to be correct.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Alternatives to the Affero General Public License

[Jeff Licquia]

On Wed, 2005-06-22 at 10:19 -0700, Gregor Richards wrote:
> In response to "Still unworkable.  I want to use the code for some
> embedded use ..."
> How is this unworkable?  To support the HTTP protocol to the degree of
> sending source code does not require a full HTTP sever per se.  Hell,
> you could just receive input and ignore it until a blank line, then send
> Content-type: application/octet-stream
> 
> 
> 
> 
> and make a suitable "HTTP server" in about 25 lines of code.  Any device
> with networking capability could support such a simplNobody said it
> needed to support sending any other files, etc.

I submit that there are embedded environments that will, despite your
helpful 25 "line" (assembly?  C?  Java?) HTTP server, not have the
capacity to include it.

But let's say that your 25-line HTTP server, with a few tweaks, can be
made to fit in absolutely every net-connected embedded device in
existence.  Now where do you put the source archive the HTTP server is
supposed to serve?

You could, I suppose, mandate to the poor developer that he has to add
sufficient flash memory to the device to hold the source.  But now we're
talking about using the law to mandate design decisions against the
developer's wishes.  I don't know what definition of free gives you the
right to tell developers how much memory their devices must, by law,
have; none of them I have heard does so.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Gregor Richards]

On Wed, 22 Jun 2005 16:04:27 -0500, "Jeff Licquia" <[EMAIL PROTECTED]>
said:
> On Wed, 2005-06-22 at 10:19 -0700, Gregor Richards wrote:
> > In response to "Still unworkable.  I want to use the code for some
> > embedded use ..."
> > How is this unworkable?  To support the HTTP protocol to the degree of
> > sending source code does not require a full HTTP sever per se.  Hell,
> > you could just receive input and ignore it until a blank line, then send
> > Content-type: application/octet-stream
> > 
> > 
> > 
> > 
> > and make a suitable "HTTP server" in about 25 lines of code.  Any device
> > with networking capability could support such a simplNobody said it
> > needed to support sending any other files, etc.
> 
> I submit that there are embedded environments that will, despite your
> helpful 25 "line" (assembly?  C?  Java?) HTTP server, not have the
> capacity to include it.
> 
> But let's say that your 25-line HTTP server, with a few tweaks, can be
> made to fit in absolutely every net-connected embedded device in
> existence.  Now where do you put the source archive the HTTP server is
> supposed to serve?
> 
> You could, I suppose, mandate to the poor developer that he has to add
> sufficient flash memory to the device to hold the source.  But now we're
> talking about using the law to mandate design decisions against the
> developer's wishes.  I don't know what definition of free gives you the
> right to tell developers how much memory their devices must, by law,
> have; none of them I have heard does so.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 


So let me ask this (I also put this somewhere else, but it's lost to the
thread now ;) )
If the alternatives provided by clause 3 of the GNU GPL were also
options, would that be an improvement?  That is, if, instead of
providing source within the page itself, an offer to provide source was
given, would that work?
I suppose the issue here is that you certainly couldn't give a physical,
printed, written offer to every one who used a web server, but then, it
may be reasonable to put "source is available on request to ..." in the
output.
There's another problem posed by that, though ... if somebody modified
the version, and forgot to change that line ... disaster.

 - Gregor Richards
-- 
  Gregor Richards
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - Access all of your messages and folders
  wherever you are


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Mark Rafn]

On Wed, 22 Jun 2005, Gregor Richards wrote:


If the alternatives provided by clause 3 of the GNU GPL were also
options, would that be an improvement?  That is, if, instead of
providing source within the page itself, an offer to provide source was
given, would that work?


I believe this to be an improvement, and it will make your job of creating 
a clear document easier.  I don't believe it makes the requirement 
compatible with free software.



I suppose the issue here is that you certainly couldn't give a physical,
printed, written offer to every one who used a web server, but then, it
may be reasonable to put "source is available on request to ..." in the
output.


If there IS human-readable output, and that output is unimportant enough 
that offtopic text about licensing doesn't interfere with the 
functionality, this is an improvement.  It's still not free, but it's an 
improvement you should consider.  Much like a $10 license fee is less 
painful than a $200 fee, and neither is free.


I'd like to encourage you to think less along the lines "it's currently a 
web server, so the license should cater to that case" and more like 
"people should be able to make things out of this that I haven't thought 
of, using methodologies yet undreamt".  This can't happen if you're 
prescribing things like network protocols, output text, or specific 
behaviors.


If I can't turn it into a random-number service that runs on my phone over 
some crazy bluetooth RPC mechanism, it ain't free.

--
Mark Rafn[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Gregor Richards]

Mark Rafn wrote:

I'd like to encourage you to think less along the lines "it's 
currently a web server, so the license should cater to that case" and 
more like "people should be able to make things out of this that I 
haven't thought of, using methodologies yet undreamt". This can't 
happen if you're prescribing things like network protocols, output 
text, or specific behaviors.


If I can't turn it into a random-number service that runs on my phone 
over some crazy bluetooth RPC mechanism, it ain't free.



I've been considering this, and have written a completely different 
clause, with no mention of computer networks, HTTP, or anything such. It 
might, however, be more difficult to enforce. I tried to write it in 
such a way that giving somebody SSH access to your computer does not 
necessitate providing source for all of your programs under this license 
... that was the hardest part, and makes it read a bit kludgely.
I doubt that it is compliant with the Dissident Problem by your opinions 
(< plural your), but I think that it's well within line of all of the 
other requirements, and as an added bonus isn't tied to any particular 
technology.

This would not be 2(d), but a new clause between 3 and 4.


If you provide to a person or persons a means of accessing an 
interactive interface to the Program which does not include access to 
the source code, object code or executable, you must also provide to 
that person or those persons (henceforth called "Indirect Users") access 
to the complete source code of the Program in one of the following ways:
a) Cause the Program to provide its source code in said interactive 
interface upon the request of an Indirect User; or,
b) Make a means of immediate retrieval of the Program's source code 
easily visible to all Indirect Users; or,
c) Provide a written offer, easily visible to all Indirect Users and 
valid for at least three years, to give to any third party, for a charge 
no more than your cost of physically performing source distribution, a 
complete machine-readable copy of the corresponding source code, to be 
distributed under the terms of Sections 1 and 2 above on a medium 
customarily used for software interchange.


Thoughts?

- Gregor Richards

PS: While it would be great for me if I could find some way to get a 
license with some provision like this considered DFSG free (nothing is 
impossible! ;) ), I would also like your opinions on whether you think 
that this would cause any undue harm besides non-DFSG-compliance 
(unnecessary trouble for innocent users, etc)



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Alternatives to the Affero General Public License

[Gregor Richards]

On Wed, 22 Jun 2005 20:36:50 -0700, "Gregor Richards" <[EMAIL PROTECTED]>
said:
> Mark Rafn wrote:
> 
> > I'd like to encourage you to think less along the lines "it's 
> > currently a web server, so the license should cater to that case" and 
> > more like "people should be able to make things out of this that I 
> > haven't thought of, using methodologies yet undreamt". This can't 
> > happen if you're prescribing things like network protocols, output 
> > text, or specific behaviors.
> >
> > If I can't turn it into a random-number service that runs on my phone 
> > over some crazy bluetooth RPC mechanism, it ain't free.
> 
> 
> I've been considering this, and have written a completely different 
> clause, with no mention of computer networks, HTTP, or anything such. It 
> might, however, be more difficult to enforce. I tried to write it in 
> such a way that giving somebody SSH access to your computer does not 
> necessitate providing source for all of your programs under this license 
> ... that was the hardest part, and makes it read a bit kludgely.
> I doubt that it is compliant with the Dissident Problem by your opinions 
> (< plural your), but I think that it's well within line of all of the 
> other requirements, and as an added bonus isn't tied to any particular 
> technology.
> This would not be 2(d), but a new clause between 3 and 4.
> 
> 
> If you provide to a person or persons a means of accessing an 
> interactive interface to the Program which does not include access to 
> the source code, object code or executable, you must also provide to 
> that person or those persons (henceforth called "Indirect Users") access 
> to the complete source code of the Program in one of the following ways:
> a) Cause the Program to provide its source code in said interactive 
> interface upon the request of an Indirect User; or,
> b) Make a means of immediate retrieval of the Program's source code 
> easily visible to all Indirect Users; or,
> c) Provide a written offer, easily visible to all Indirect Users and 
> valid for at least three years, to give to any third party, for a charge 
> no more than your cost of physically performing source distribution, a 
> complete machine-readable copy of the corresponding source code, to be 
> distributed under the terms of Sections 1 and 2 above on a medium 
> customarily used for software interchange.
> 
> Thoughts?
> 
> - Gregor Richards
> 
> PS: While it would be great for me if I could find some way to get a 
> license with some provision like this considered DFSG free (nothing is 
> impossible! ;) ), I would also like your opinions on whether you think 
> that this would cause any undue harm besides non-DFSG-compliance 
> (unnecessary trouble for innocent users, etc)
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 


Damn ... I just posted the email address that I was hoping not to get
posted on line.  That sender is me, I'm that sender, and damn it, there
is now going to be a link to my email address for all spam bots to read
>_<

/me slaps himself in the head.

 - Gregor Richards
-- 
  Gregor Richards
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]