subject:"Re\: Berkeley DB 6.0 license change to AGPLv3"

On Wednesday, July 10, 2013 01:06:47 PM Stefano Zacchiroli wrote:
 On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote:
  No, there is a really important difference. With GPL you only have to be
  careful when you give binaries to anyone, that you also give the source.
  This is a bit of a hassle, but worst case means that you cannot help
  others with the software changes you have done (bad enough but worth the
  hassle to have the source) if you miss some of the sources. But if the
  sources may contain any passwords or other internal data you cannot/do
  not want to share, so will likely the binary so that is no difference.
 
 On this level, the analogy GPL/AGPL still seems correct to me.
 
 A software distributed under AGPL will likely come with mechanisms
 already in place to point to its source code --- that might not be the
 case today yet, due to the scarce popularity of AGPL, but that's a
 separate matter.  That means that you can easily run unmodified version
 of an AGPL'd program, for any purpose, without particular restrictions.
 
 If you modify the software you might get in trouble but, according to my
 personal ethics, that's the trouble you should have. However, please
 note that as long as you run the software only for yourself, you don't
 have any problem. You might encounter problems only in the case you've
 modified the software, you want *others* to use it over the net, and you
 don't provide the source code that include your modifications.
 
 That shift is coherent with the shift in the most common deployment
 pattern for software: handing software copies in the past, using remote
 services over the net nowadays.
 
 (Anyway, here we're getting quite off-topic...)

Sorry, I can't quite let this pass.  I just went and looked at the AGPL v3 
again and one implication of the license is that you can't locally fix a 
security issue without immediate disclosure.  This doesn't fit my personal 
ethics at all and at least IMO makes it pretty unsuitable as a license for any 
network facing service.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Adam Borowski

On Wed, Jul 10, 2013 at 08:18:12AM -0400, Scott Kitterman wrote:
 Sorry, I can't quite let this pass.  I just went and looked at the AGPL v3 
 again and one implication of the license is that you can't locally fix a 
 security issue without immediate disclosure.  This doesn't fit my personal 
 ethics at all and at least IMO makes it pretty unsuitable as a license for 
 any 
 network facing service.

You can!

There is just one caveat: you must make sure to never, ever, distribute that
piece of software, because once you do, you permanently lose your right to
use it without obnoxious and potentially crippling restrictions.

That's section 9 of AGPL v3.

So we have non-redistributable software in the main archive.  The
alternative you are allowed to (accepting the license) can't be
considered free, as it outright violates FSF's freedom 0 (The freedom
to run the program, for any purpose) and DFSG 6 (No discrimination
against fields of endeavor).  AGPLed code can't be used for pretty
much anything that's neither a web service nor restricted solely to
a single computer.

As already mentioned in so many places, interesting banned uses include
reusing any part of the code in:
* a POP3/IMAP server
* an IRC bot that doesn't spam every user with legal messages
* a SMS/etc service
* a kiosk
* a wifi-connected lift control (don't laugh, I've seen one at Google)

Per section 13, any derived software that supports remote interaction
through a computer network must present a prominent offer to every user,
no matter if that's feasible or possible.  And this applies even if you
lift just several lines of code, even ancillary.  For example, two of my
personal projects include autoconfage that detects the way of spawning
ptys, copied from GNU screen, without using any part of screen proper.
Even such a minor code reuse is effectively banned by the AGPL -- both
of those projects include networking, and only one can reasonably present
an URL to its users.

The official FTPmaster response came in #495721, and it doesn't even
mention this issue, only three minor points (cost of running a webserver
with sources, private use, contaminating reverse dependencies).
Thus, could someone please explain, are there any arguments that
forbidding reuse with any protocols that don't support sending bulk
ancillary text would be free?  What I can see are debian-legal threads
considering AGPL to be non-free, and, in other places like the FTPmasters
response, avoiding this issue.

That it's uncomfortable doesn't make it any less valid.  The archive
carries a non-free section just for cases like this.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130710135003.ga5...@angband.pl

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Bastian Blank

On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
 There is just one caveat: you must make sure to never, ever, distribute that
 piece of software, because once you do, you permanently lose your right to
 use it without obnoxious and potentially crippling restrictions.

Not right. You have to allow _access_ to it via a computer network.

 That's section 9 of AGPL v3.

Please read section 9 of GPL v3, it is identical.

 Per section 13, any derived software that supports remote interaction
 through a computer network must present a prominent offer to every user,
 no matter if that's feasible or possible.

You miss a vital part of this sentence: (if your version supports such
interaction). Please quote complete sentences if you try to proof
something.

 The official FTPmaster response came in #495721, and it doesn't even
 mention this issue, only three minor points (cost of running a webserver
 with sources, private use, contaminating reverse dependencies).

GPL also contaminates its reverse dependencies. So what? Okay, in this
case you actually have to do something for it.

 Thus, could someone please explain, are there any arguments that
 forbidding reuse with any protocols that don't support sending bulk
 ancillary text would be free?

Okay, you did not read it.

Bastian

-- 
The heart is not a logical organ.
-- Dr. Janet Wallace, The Deadly Years, stardate 3479.4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130710150320.gb8...@mail.waldi.eu.org

Re: Berkeley DB 6.0 license change to AGPLv3

On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
 On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
  There is just one caveat: you must make sure to never, ever, distribute
  that piece of software, because once you do, you permanently lose your
  right to use it without obnoxious and potentially crippling restrictions.
 
 Not right. You have to allow _access_ to it via a computer network.
 
  That's section 9 of AGPL v3.
 
 Please read section 9 of GPL v3, it is identical.
 
  Per section 13, any derived software that supports remote interaction
  through a computer network must present a prominent offer to every user,
  no matter if that's feasible or possible.
 
 You miss a vital part of this sentence: (if your version supports such
 interaction). Please quote complete sentences if you try to proof
 something.
 
  The official FTPmaster response came in #495721, and it doesn't even
  mention this issue, only three minor points (cost of running a webserver
  with sources, private use, contaminating reverse dependencies).
 
 GPL also contaminates its reverse dependencies. So what? Okay, in this
 case you actually have to do something for it.

It's precisely the forced distribution of modifications that makes it 
unsuitable for any use that is any way security sensitive.  If you take a 
GPLv3 web server (as an example) and it is built by your distributor against 
the AGPL libdb version, the combined work is effectively AGPL, which means if 
you use a local security fix on your web server, you've violated the terms 
under which you've received the code.  Totally unsuitable.  It doesn't matter 
if libdb supports network interaction or not.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4241872.WOu7pss5Jc@scott-latitude-e6320

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Adam Borowski

On Wed, Jul 10, 2013 at 05:03:20PM +0200, Bastian Blank wrote:
 On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
  There is just one caveat: you must make sure to never, ever, distribute that
  piece of software, because once you do, you permanently lose your right to
  use it without obnoxious and potentially crippling restrictions.
 
 Not right. You have to allow _access_ to it via a computer network.

Which you can do without distributing the code, thus accepting the license
is not required.  You can _run_ the code you received, just not distribute
it to third parties.

  That's section 9 of AGPL v3.
 
 Please read section 9 of GPL v3, it is identical.

Yes, you can run code under regular GPL without accepting is as well; which
is a moot point as the GPL contains no use restrictions.

  Per section 13, any derived software that supports remote interaction
  through a computer network must present a prominent offer to every user,
  no matter if that's feasible or possible.
 
 You miss a vital part of this sentence: (if your version supports such
 interaction).

An IMAP server does support remote interaction through a computer network.

 Please quote complete sentences if you try to proof something.

I did, replacing the word such with the definition it refers to, mentioned
before the text I quoted.

  The official FTPmaster response came in #495721, and it doesn't even
  mention this issue, only three minor points (cost of running a webserver
  with sources, private use, contaminating reverse dependencies).
 
 GPL also contaminates its reverse dependencies. So what? Okay, in this
 case you actually have to do something for it.

Any license without a linking exception contaminates parts that rely on it,
and so does copying fragments of code.  You include a single function under
a BSD license?  You need to fulfill its requirements, ie keep the notices,
forever, as long as you keep including that function.  That's why this is
not a relevant argument against AGPL  But none of the above three points
are what I'm talking about here.

  Thus, could someone please explain, are there any arguments that
  forbidding reuse with any protocols that don't support sending bulk
  ancillary text would be free?
 
 Okay, you did not read it.

What?

Please point me to any other license in main that has an _use_ restriction. 
You often have to jump through hops as for what kind of modifications remain
distributable, but no DFSG-free license restricts:
* local modifications
* use


-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130710155647.ga7...@angband.pl

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Clint Byrum

Excerpts from Scott Kitterman's message of 2013-07-10 08:28:54 -0700:
 On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
  On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
   There is just one caveat: you must make sure to never, ever, distribute
   that piece of software, because once you do, you permanently lose your
   right to use it without obnoxious and potentially crippling restrictions.
  
  Not right. You have to allow _access_ to it via a computer network.
  
   That's section 9 of AGPL v3.
  
  Please read section 9 of GPL v3, it is identical.
  
   Per section 13, any derived software that supports remote interaction
   through a computer network must present a prominent offer to every user,
   no matter if that's feasible or possible.
  
  You miss a vital part of this sentence: (if your version supports such
  interaction). Please quote complete sentences if you try to proof
  something.
  
   The official FTPmaster response came in #495721, and it doesn't even
   mention this issue, only three minor points (cost of running a webserver
   with sources, private use, contaminating reverse dependencies).
  
  GPL also contaminates its reverse dependencies. So what? Okay, in this
  case you actually have to do something for it.
 
 It's precisely the forced distribution of modifications that makes it 
 unsuitable for any use that is any way security sensitive.  If you take a 
 GPLv3 web server (as an example) and it is built by your distributor against 
 the AGPL libdb version, the combined work is effectively AGPL, which means if 
 you use a local security fix on your web server, you've violated the terms 
 under which you've received the code.  Totally unsuitable.  It doesn't matter 
 if libdb supports network interaction or not.
 

Clause 13 again:

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.

First off, I think the AGPL is far too vague and fails at its goals of
assuring user freedom when interacting with software over the net. If the
goal was to make sure web apps like MediaGoblin and Wordpress weren't
turned into big commercial services without giving the code back to
the users, then specific clauses would have made a lot more sense. The
vagueness of the interacting with it remotely through a computer network
part is particulary frustrating and has led to the AGPL being a tool
for legal bludgeoning.

Given the scenario Scott brings up above, AGPL for a webserver would be
a disaster. Thus, any plumbing/libraries/etc. are really bad candidates
for AGPL. This rather subtle imbalance is why MongoDB being AGPL leads to
10gen being able to shake down commercial entities who use MongoDB. They
may have thought they were getting Free software, but suddenly they have
to start considering whether or not they have to provide the source for
whatever version of MongoDB they might be running. Legally one could make
an argument that their proprietary webapp is just acting as a proxy for
the users to interact with MongoDB.

I'm not saying that argument is right, and I am not a lawyer, but I do
know that lawyers hate vagueness for this exact reason.

I do think AGPL complies with all of the clauses of the DFSG. There is
very little difference in an AGPLv3 licensed library as a GPLv3 licensed
library. Before linking, one must always check the library license. If
we do let BDB 6.0 into Debian with its new AGPL license, it is on the
BDB maintainer(s) to file RC bugs in the reverse dependencies to help
maintainers avoid accidentally shipping AGPL licensed binaries that are
not in compliance with the AGPL.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1373472124-sup-4...@fewbar.com

Re: Berkeley DB 6.0 license change to AGPLv3

On Wednesday, July 10, 2013 09:20:37 AM Clint Byrum wrote:
 Excerpts from Scott Kitterman's message of 2013-07-10 08:28:54 -0700:
  On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
   On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
There is just one caveat: you must make sure to never, ever,
distribute
that piece of software, because once you do, you permanently lose your
right to use it without obnoxious and potentially crippling
restrictions.
   
   Not right. You have to allow _access_ to it via a computer network.
   
That's section 9 of AGPL v3.
   
   Please read section 9 of GPL v3, it is identical.
   
Per section 13, any derived software that supports remote interaction
through a computer network must present a prominent offer to every
user,
no matter if that's feasible or possible.
   
   You miss a vital part of this sentence: (if your version supports such
   interaction). Please quote complete sentences if you try to proof
   something.
   
The official FTPmaster response came in #495721, and it doesn't even
mention this issue, only three minor points (cost of running a
webserver
with sources, private use, contaminating reverse dependencies).
   
   GPL also contaminates its reverse dependencies. So what? Okay, in this
   case you actually have to do something for it.
  
  It's precisely the forced distribution of modifications that makes it
  unsuitable for any use that is any way security sensitive.  If you take a
  GPLv3 web server (as an example) and it is built by your distributor
  against the AGPL libdb version, the combined work is effectively AGPL,
  which means if you use a local security fix on your web server, you've
  violated the terms under which you've received the code.  Totally
  unsuitable.  It doesn't matter if libdb supports network interaction or
  not.
 
 Clause 13 again:
 
 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.
 
 First off, I think the AGPL is far too vague and fails at its goals of
 assuring user freedom when interacting with software over the net. If the
 goal was to make sure web apps like MediaGoblin and Wordpress weren't
 turned into big commercial services without giving the code back to
 the users, then specific clauses would have made a lot more sense. The
 vagueness of the interacting with it remotely through a computer network
 part is particulary frustrating and has led to the AGPL being a tool
 for legal bludgeoning.
 
 Given the scenario Scott brings up above, AGPL for a webserver would be
 a disaster. Thus, any plumbing/libraries/etc. are really bad candidates
 for AGPL. This rather subtle imbalance is why MongoDB being AGPL leads to
 10gen being able to shake down commercial entities who use MongoDB. They
 may have thought they were getting Free software, but suddenly they have
 to start considering whether or not they have to provide the source for
 whatever version of MongoDB they might be running. Legally one could make
 an argument that their proprietary webapp is just acting as a proxy for
 the users to interact with MongoDB.
 
 I'm not saying that argument is right, and I am not a lawyer, but I do
 know that lawyers hate vagueness for this exact reason.
 
 I do think AGPL complies with all of the clauses of the DFSG. There is
 very little difference in an AGPLv3 licensed library as a GPLv3 licensed
 library. Before linking, one must always check the library license. If
 we do let BDB 6.0 into Debian with its new AGPL license, it is on the
 BDB maintainer(s) to file RC bugs in the reverse dependencies to help
 maintainers avoid accidentally shipping AGPL licensed binaries that are
 not in compliance with the AGPL.

I'm already talking with upstreams to make sure mdb is supported for packages 
I maintain.  I'm certainly not planning on effectively making anything AGPL.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/3786443.229gZ0kdxN@scott-latitude-e6320

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Russ Allbery

Clint Byrum spam...@debian.org writes:

 I do think AGPL complies with all of the clauses of the DFSG. There is
 very little difference in an AGPLv3 licensed library as a GPLv3 licensed
 library.

I agree from a licensing standpoint.

I think that, from a security standpoint, an AGPLv3 license on a library
puts any software that links with that library in an extremely awkward and
surprising security situation due to the prohibition on locally patching
security vulnerabilities without disclosure.  Personally, I would decline
to package any such software for Debian for that reason.  That's the sort
of surprise that I'm not interested in springing on my users.  Those kind
of license terms are very awkward in an enterprise environment.

For example, I would consider such software undeployable at Stanford.
We're a very free-software-friendly place, but there's no way that I would
give up the right to patch security vulnerabilities whenever and however I
want without immediately disclosing the fix.  I have frequently deployed
escrowed security fixes on publicly-accessible test/dev systems for
testing purposes, and in fact consider my ability to do that a necessary
prerequisite for being able to properly support the Debian packaging.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppuql0ll@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Bernhard R. Link

* Stefano Zacchiroli z...@debian.org [130710 13:07]:
 On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote:
  No, there is a really important difference. With GPL you only have to be
  careful when you give binaries to anyone, that you also give the source.
  This is a bit of a hassle, but worst case means that you cannot help
  others with the software changes you have done (bad enough but worth the
  hassle to have the source) if you miss some of the sources. But if the
  sources may contain any passwords or other internal data you cannot/do
  not want to share, so will likely the binary so that is no difference.

 On this level, the analogy GPL/AGPL still seems correct to me.

For me GPL is like police patroling in the streets and AGPL is like
policy getting the right to visit my bedroom at evening to look under
the bed for monsters at their discretion.

 A software distributed under AGPL will likely come with mechanisms
 already in place to point to its source code --- that might not be the
 case today yet, due to the scarce popularity of AGPL, but that's a
 separate matter.  That means that you can easily run unmodified version
 of an AGPL'd program, for any purpose, without particular restrictions.

I hope will all agree that the unmodified case does not matter at all.

 If you modify the software you might get in trouble but, according to my
 personal ethics, that's the trouble you should have.

I accept that I am not allowed to modify some software. But I refuse to
call such software free.

 However, please
 note that as long as you run the software only for yourself, you don't
 have any problem.

This is not the 1990ties anymore. Not allowing net access is quite an
big contraint. Some better definitions might reduce the problem here.

But given the way section is formulated I see nothing that would
make an exception for something only used by me and everyone else
interacting with it only by getting a loging prompt and a failure
message when they do not provide my username and password.

 You might encounter problems only in the case you've
 modified the software, you want *others* to use it over the net, and you
 don't provide the source code that include your modifications.

So if I patch a IRC client for my personal use to also show me some
other information (as I do not want too many open windows) and that
client contains AGPL code, does that fall under section 13 (assuming
it supports CTCP)? Have I lost the right to patch my programs locally
in a quick and dirty way embedding hostnames and passwords and logic
to access some private services in it without implementing a fake-irc
server for that information or some general message passing mechanism?

Even if defining the undefined interacting to need more interaction,
let's look at some website provided by some of the all-in-one thing.
Assume it has some content mangement part, partly showing public
information, partly only accessible by me (or if I in this example
was a company by my employees). And also a blog with comments (as
I think it will hard to define interacting so narrowly that it
will not contain that). Now if I want the private part to show me
some information from some other source, I am again forced to have
split things 'cleanly' on my systems with AGPL.

 That shift is coherent with the shift in the most common deployment
 [...]

Not every solution can be shifted. If some fly does not allow me
to sleep by its noise, I will either kill it or open an window and
throw it out. But if I had a cat and that would be too loud, neighter
would be a solution (perhaps the second if I lived at ground
floor). And if you have a baby, ...

There can be no freedom without restricting them to actually have them
in the one way or the other. But for such a restriction to be justified,
it needs both to be effective in protecting another freedom and not
cause greater harm than it brings.

In every way I see that you could make the definitions, AGPL will fail
at the one or the other:

Assume a AGPL program being modified or a program using AGPL libraries
to be interacting only via answering HTTP Requests and returning all
it's source code when /source.tar.gz is requested and giving proper
notice of this and the license and so on.

Either the AGPL permits such a program (or any AGPL program transformed
into such a program) to be run bound to a private IP or localhost
and all user interaction via a reverse proxy or loadbalancer that
returns 403 for /source.tar.gz or it forbids it.

In the first case the added restrictions are totally useless, especially
against the big software as a service players that it claims to
target, as those will likely have some loadbalancer doing some filtering
anyway.

In the second case it the restrictions to my freedom are so severe, that
I cannot see how it can do more harm than good. What worth has the
source to all the software in the world and the right to modify it, if
I lose the right to run things on my

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-10 Thread Holger Levsen

Hi,

On Mittwoch, 10. Juli 2013, Russ Allbery wrote:
 Clint Byrum spam...@debian.org writes:
  I do think AGPL complies with all of the clauses of the DFSG. There is
  very little difference in an AGPLv3 licensed library as a GPLv3 licensed
  library.
 
 I agree from a licensing standpoint.
 
 I think that, from a security standpoint, an AGPLv3 license on a library
 puts any software that links with that library in an extremely awkward and
 surprising security situation due to the prohibition on locally patching
 security vulnerabilities without disclosure. [...]
 Those kind of license terms are very awkward [...]

ouch :(

Thanks for waking me up, Russ. :-)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: Berkeley DB 6.0 license change to AGPLv3

On Saturday, July 06, 2013 01:52:59 PM Howard Chu wrote:
 Florian Weimer wrote:
  * Howard Chu:
  LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of
  source, there's nowhere to hide any tricks anyway.)
  
  Okay, I found a snag: the 511 bytes limit on the key size.  Berkeley
  DB's disk format does not impose a limit on key or value size (at
  least for B-trees).  For some applications, this will introduce new
  error conditions, and working around this limitation requires
  reworking the database schema.
 
 True. There's a bit of leeway here, we can raise the key size to ~1/2 the
 page size if necessary. But ultimately, we don't support keys that don't
 fit in a single page and there are no plans to add such support. If we see
 enough apps that can't live with this, we may revisit the situation.

I did go back and look at the plans for mdb integration in Postfix, since it's 
my MTA of choice.  It does seem that there are some barriers to adoption:

http://www.postfix.com/LMDB_README.html

Are there any plans to address these issues?

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2322910.gezk5TMbzA@scott-latitude-e6320

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-06 Thread Florian Weimer

* Philipp Kern:

 On 2013-07-04 10:04, Florian Weimer wrote:
 * Stefano Zacchiroli:
 I mean, sure, it *is* more tricky to provide such a URL for users that
 will be running a *modified* version of INN. But it is exactly the
 same
 kind of difficulties that people distributing modified copylefted
 software will have to face to uphold GPL (or equivalent) terms.
 We ship package building software which produces source and binary
 packages.  You just copy all of them and are compliant.

 We currently do not ship a licensing server that helps users with AGPL
 compliance.

 I guess we'd need a way to repack the source used to build into the
 binary, to at least make it possible to add a webserver and serve
 that. (Obviously the binary must allow paths to the source
 configurable in configuration files.)

Or the software could embed a hash of its sources, contact the license
server to obtain a public URL for the corresponding source code from
that hash (with the idea that it will later be provided to clients),
and refuses to start if the license server is unreachable or does not
know anything about the hash.

 My main concern with the license is that compliance is difficult even
 for those who have no problem whatsoever with sharing their boring
 local changes.  I'm concerned that we're heading to the Linux (kernel)
 land where Android and others have made GPL compliance a farce.

 Like RedHat? ;-)

We're just using our right to make anonymous changes under the
Dissident Test. :-)

(The sources at

ftp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-358.11.1.el6.src.rpm

are used to build the kernel currently shipped to customers.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vc4n3ktw@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-06 Thread Bernhard R. Link

* Stefano Zacchiroli z...@debian.org [130704 09:24]:
 I mean, sure, it *is* more tricky to provide such a URL for users that
 will be running a *modified* version of INN. But it is exactly the same
 kind of difficulties that people distributing modified copylefted
 software will have to face to uphold GPL (or equivalent) terms.

No, there is a really important difference. With GPL you only have to be
careful when you give binaries to anyone, that you also give the source.
This is a bit of a hassle, but worst case means that you cannot help
others with the software changes you have done (bad enough but worth the
hassle to have the source) if you miss some of the sources. But if the
sources may contain any passwords or other internal data you cannot/do
not want to share, so will likely the binary so that is no difference.

With AGPL you are no longer allowed to run the software in this case.
I do not see how a software restricting running a software can still
be called free.

Low quality software modifications are not the best. It would be far
nicer if anyone just wrote nice general frameworks for their specific
needs and submitted them upstream. But limiting the users freedom to
be able to do and finance that is absurd. If you are no longer allowed
to make some quick and dirty modifications to make our software work
for you, then in the sum it is no more free at all.

 For people who
 are fine with the copyleft approach (and of course not all of us are)
 AGPL shouldn't be particularly shocking.

Sorry, once I am no longer allowed to run some software on my computer
because I modified it to my needs, then it simply is not free. People
still calling that free is shocking for me indeed.

 In that sense, AGPL is just a
 new release of GPL that closes a long outstanding bug titled provide a
 license port for the Software-as-a-Service era.

And adding DRM to the browser is just closing a long outstanding bug
titled please cripple my system enough so that content providers will
take my money?

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130706154116.ga3...@client.brlink.eu

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-06 Thread Florian Weimer

* Howard Chu:

 LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of
 source, there's nowhere to hide any tricks anyway.)

Okay, I found a snag: the 511 bytes limit on the key size.  Berkeley
DB's disk format does not impose a limit on key or value size (at
least for B-trees).  For some applications, this will introduce new
error conditions, and working around this limitation requires
reworking the database schema.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u7bv2qj@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-06 Thread Howard Chu


Florian Weimer wrote:

* Howard Chu:


LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of
source, there's nowhere to hide any tricks anyway.)


Okay, I found a snag: the 511 bytes limit on the key size.  Berkeley
DB's disk format does not impose a limit on key or value size (at
least for B-trees).  For some applications, this will introduce new
error conditions, and working around this limitation requires
reworking the database schema.


True. There's a bit of leeway here, we can raise the key size to ~1/2 the page 
size if necessary. But ultimately, we don't support keys that don't fit in a 
single page and there are no plans to add such support. If we see enough apps 
that can't live with this, we may revisit the situation.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d883ab.8000...@symas.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-05 Thread Ondřej Surý

On Fri, Jul 5, 2013 at 12:07 AM, Bálint Réczey bal...@balintreczey.huwrote:

 We could keep libdb-dev for the fork keeping the current license and create
 a new set of development packages like libdb6-dev for the AGPLv3 code
 with or without switching to an upstream different from Oracle.


And if you read the thread backwards, that's exactly the thing we want to
avoid. For the sanity we want to have just one active version of BDB in the
archive (we usually need the old tools).

Database files created with different versions might be incompatible[1]
(depends on the features you use, but usually the on-disk log format
changes with every release), and you certainly don't want to have f.e.
python compiled with BDB 6.0 and Perl compiled with BDB 5.3. The would be
mess we were able to avoid in wheezy and I don't want to have it back
(squeeze had a random mix of db4.7 and db4.8).

1.
http://docs.oracle.com/cd/E17275_01/html/programmer_reference/upgrade_process.html(e.g.
once you call DB-upgrade from program or dbX.Y_upgrade from command
line, there's no guarantee that the applications compiled with old Berkeley
DB will be able to work with the upgraded database.)

To recap: We want just one Berkeley DB version and we need one compatible
with existing application's licenses.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-05 Thread Philipp Kern


On 2013-07-04 10:04, Florian Weimer wrote:

* Stefano Zacchiroli:

I mean, sure, it *is* more tricky to provide such a URL for users that
will be running a *modified* version of INN. But it is exactly the 
same

kind of difficulties that people distributing modified copylefted
software will have to face to uphold GPL (or equivalent) terms.

We ship package building software which produces source and binary
packages.  You just copy all of them and are compliant.

We currently do not ship a licensing server that helps users with AGPL
compliance.


I guess we'd need a way to repack the source used to build into the 
binary, to at least make it possible to add a webserver and serve that. 
(Obviously the binary must allow paths to the source configurable in 
configuration files.)



My main concern with the license is that compliance is difficult even
for those who have no problem whatsoever with sharing their boring
local changes.  I'm concerned that we're heading to the Linux (kernel)
land where Android and others have made GPL compliance a farce.


Like RedHat? ;-)

SCNR
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/9e79656e1aacad48bf23129b3a986...@hub.kern.lc

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Stefano Zacchiroli

Hi Bradley, and thanks for your comments.

On Wed, Jul 03, 2013 at 11:34:38AM -0400, Bradley M. Kuhn wrote:
 BTW, I'd suggest a rather unorthodox solution if developers are
 interested: fork this AGPLv3'd version of BDB, and begin making
 substantial improvements and changes under AGPLv3.  That way, Oracle
 isn't the sole copyright holder,

That is a pretty interesting proposal, indeed.

 and if Oracle were to take action under a clause of AGPLv3, other
 copyright holders could intervene and indicate they disagreed with
 Oracle.  If the case went to litigation, Oracle would have a tough
 time because the other copyright holders would be expert witnesses (in
 the USA sense -- not sure what the equivalent is elsewhere in the
 world) who were saying Oracle was acting unfairly and over-reading the
 license terms.  (I'd certainly be willing to be an expert witness as
 the license's co-author in such cases.)

So, I wonder, do we have any idea (due to them having already been
mentioned publicly elsewhere) about the craziest interpretation of AGPL
that the evil guys might come up with and, at the other end of the
spectrum, the most restrictive one? AFAIK AGPL hasn't been tested in
court, yet. But I can't help wondering what people are really scared
about here.

Is it the quine scenario (IMHO ruled out by the license text, but
obviously you never know...) that people fear to have to implement,
worrying about the fact that simply providing URLs to tarballs wouldn't
be considered enough? Or is it something else?

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Stefano Zacchiroli

On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote:
 As an upstream for INN, I think doing such a thing would be completely
 absurd, and would rather just drop Berkeley DB support entirely and make
 everyone switch to a different overview method than do anything of the
 sort.

I'm curious, can you elaborate on why as upstream you'd refuse to add
something like a protocol command that return a URL pointing to a
tarball containing the source code of the INN version the users are
running? At times, I'm really surprised by the upfront opposition that
AGPL could get in Free Software cycles and I'd like to understand more
your motives as an upstream.

I mean, sure, it *is* more tricky to provide such a URL for users that
will be running a *modified* version of INN. But it is exactly the same
kind of difficulties that people distributing modified copylefted
software will have to face to uphold GPL (or equivalent) terms.

AGPL is really nothing more than the adaptation of copyleft to a world
where software usage has shifted from compiled binaries people run on
their computers, to services they access over the net.  For people who
are fine with the copyleft approach (and of course not all of us are)
AGPL shouldn't be particularly shocking. In that sense, AGPL is just a
new release of GPL that closes a long outstanding bug titled provide a
license port for the Software-as-a-Service era.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Russ Allbery

Stefano Zacchiroli z...@debian.org writes:
 On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote:

 As an upstream for INN, I think doing such a thing would be completely
 absurd, and would rather just drop Berkeley DB support entirely and
 make everyone switch to a different overview method than do anything of
 the sort.

 I'm curious, can you elaborate on why as upstream you'd refuse to add
 something like a protocol command that return a URL pointing to a
 tarball containing the source code of the INN version the users are
 running?

Does that satisfy the license?  It doesn't look to me like it does,
because it doesn't ensure that the offer is presented to every client.
The client has to go run some command.

If that's all that's required, that's trivial -- put the URL into the
motd.* files and then LIST MOTD will return it with no further involvement
on INN's part required.  I certainly have no objection to that -- I don't
have to do anything at all as upstream.  :)  But that didn't seem to be
what the license said.

 At times, I'm really surprised by the upfront opposition that AGPL could
 get in Free Software cycles and I'd like to understand more your motives
 as an upstream.

The AGPL, for software that's already free and that isn't being abused in
the ways that the AGPL was designed to address, adds a bunch of headaches
and work for precisely zero benefit.

I understand the point for things that are heavily abused, such as cloud
services in general.  But INN is not one of those things.  Besides, it
doesn't really matter if it is: INN has always been available under a
BSD-style license.  That decision was made a long time ago, and it is what
it is; I intensely dislike random third-party software trying to force
that to change.

Berkeley DB does have a copyleft license already, but it's a very
unobjectionable one as these things go.  It's much easier to deal with
than the GPL, for instance, and is trivially satisfied by software
distributed under the BSD license.  This is not at all true of the AGPL.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u7ekb7u@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Michael Banck

Hi,

On Thu, Jul 04, 2013 at 06:39:30AM +0200, Ondřej Surý wrote:
 On Thu, Jul 4, 2013 at 12:27 AM, Michael Banck mba...@debian.org wrote:
  People have pointed out upthread that Oracle does not appear to be the
  sole copyright holder of BerkelyDB.  So unless they had copyright
  assignments or similar on file, maybe a viable route would be to contact
  those additional copyright holders and suggest they complain to Oracle
  in order to get their relicensing reversed.
 
  This should probably be done in coordination with the wider Free
  Software community.
 
 From my understanding, the other copyright holders' opinion doesn't
 really matter – even if they relicense just the parts they own the
 whole work will be distributed under stricter license (e.g. AGPLv3).
 But feel free to correct me if I am wrong.

That would only work if the Sleepycat license and the AGPLv3 are
compatible I guess, is that the case?  Otherwise, I would assume the
result not to be distributable.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130704094441.gj27...@nighthawk.chemicalconnection.dyndns.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Ondřej Surý

On Thu, Jul 4, 2013 at 11:44 AM, Michael Banck mba...@debian.org wrote:

 Hi,

 On Thu, Jul 04, 2013 at 06:39:30AM +0200, Ondřej Surý wrote:
  On Thu, Jul 4, 2013 at 12:27 AM, Michael Banck mba...@debian.org
 wrote:
   People have pointed out upthread that Oracle does not appear to be the
   sole copyright holder of BerkelyDB.  So unless they had copyright
   assignments or similar on file, maybe a viable route would be to
 contact
   those additional copyright holders and suggest they complain to Oracle
   in order to get their relicensing reversed.
  
   This should probably be done in coordination with the wider Free
   Software community.
 
  From my understanding, the other copyright holders' opinion doesn't
  really matter – even if they relicense just the parts they own the
  whole work will be distributed under stricter license (e.g. AGPLv3).
  But feel free to correct me if I am wrong.

 That would only work if the Sleepycat license and the AGPLv3 are
 compatible I guess, is that the case?  Otherwise, I would assume the
 result not to be distributable.


As far as I understand it – there are some parts in Berkeley DB source code
which is just BSD licensed (and the copyright holders are those mentioned
earlier)[1], then there are parts which were under SleepyCat license and
presumably the copyright holder for those parts is Oracle – and those were
relicensed to AGPLv3. (There are also mixed files[3].)

So, the AGPLv3 just needs to be compatible with 3-clause BSD license, which
is the case.

1. f.e. src/clib/atoi.c
2. f.e. src/clib/bsearch.c
3. f.e. src/db/db.c

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Tollef Fog Heen

]] Stefano Zacchiroli 

 On Tue, Jul 02, 2013 at 09:17:13AM -0700, Russ Allbery wrote:
  As an upstream for INN, I think doing such a thing would be completely
  absurd, and would rather just drop Berkeley DB support entirely and make
  everyone switch to a different overview method than do anything of the
  sort.
 
 I'm curious, can you elaborate on why as upstream you'd refuse to add
 something like a protocol command that return a URL pointing to a
 tarball containing the source code of the INN version the users are
 running?

Not all protocols are trivially extendable, and as Russ says, you have
to ensure it's seen by all clients.  I'd not be looking forward how to
bolt that onto OpenLDAP so the offer is seen by all LDAP clients (which
then have to show the offer in their UI somehow, presumably?)

[...]

 AGPL is really nothing more than the adaptation of copyleft to a world
 where software usage has shifted from compiled binaries people run on
 their computers, to services they access over the net.

I see a distinct difference between «I'm delivering mail to somebody
(and they have to provide me with an offer to the source code of their
MTA)» and «I'm putting my data into a web service where all the logic
and computation happens on the server side and I'm just seeing the UI
bits (but they have to offer me the source code to the entire
application)».  One of them is an implementation of a standard protocol,
the other is a distributed application.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txkaob8l@qurzaw.varnish-software.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Michael Banck

Hi,

On Thu, Jul 04, 2013 at 12:29:36PM +0200, Ondřej Surý wrote:
 On Thu, Jul 4, 2013 at 11:44 AM, Michael Banck mba...@debian.org wrote:
  On Thu, Jul 04, 2013 at 06:39:30AM +0200, Ondřej Surý wrote:
   From my understanding, the other copyright holders' opinion doesn't
   really matter – even if they relicense just the parts they own the
   whole work will be distributed under stricter license (e.g. AGPLv3).
   But feel free to correct me if I am wrong.
 
  That would only work if the Sleepycat license and the AGPLv3 are
  compatible I guess, is that the case?  Otherwise, I would assume the
  result not to be distributable.
 
 As far as I understand it – there are some parts in Berkeley DB source code
 which is just BSD licensed (and the copyright holders are those mentioned
 earlier)[1], then there are parts which were under SleepyCat license and
 presumably the copyright holder for those parts is Oracle – and those were
 relicensed to AGPLv3. (There are also mixed files[3].)
 
 So, the AGPLv3 just needs to be compatible with 3-clause BSD license, which
 is the case.
 
 1. f.e. src/clib/atoi.c
 2. f.e. src/clib/bsearch.c
 3. f.e. src/db/db.c

Ah, the fact those other copyrights are under the BSD wasn't clear to
me, now it makes much more sense.


Thanks,

Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130704104849.gk27...@nighthawk.chemicalconnection.dyndns.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Vincent Lefevre

On 2013-07-04 09:23:49 +0200, Stefano Zacchiroli wrote:
 I'm curious, can you elaborate on why as upstream you'd refuse to add
 something like a protocol command that return a URL pointing to a
 tarball containing the source code of the INN version the users are
 running? At times, I'm really surprised by the upfront opposition that
 AGPL could get in Free Software cycles and I'd like to understand more
 your motives as an upstream.

What about users who patch and rebuild software locally? What should
the URL be? (Note that a file: URL couldn't even be sufficient,
as some software, such as Subversion, can be used remotely without
a shell access, so that there may be no way to fetch a file: URL
without installing a new service.)

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130704120833.ga32...@ioooi.vinc17.net

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Stefano Zacchiroli

On Thu, Jul 04, 2013 at 02:08:33PM +0200, Vincent Lefevre wrote:
 What about users who patch and rebuild software locally?

That was the second paragraph of my post (that you snipped :)), i.e.:

 I mean, sure, it *is* more tricky to provide such a URL for users that
 will be running a *modified* version of INN. But it is exactly the
 same kind of difficulties that people distributing modified copylefted
 software will have to face to uphold GPL (or equivalent) terms.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Bradley M. Kuhn

Stefano Zacchiroli wrote at 03:14 (EDT):
 So, I wonder, do we have any idea (due to them having already been
 mentioned publicly elsewhere) about the craziest interpretation of
 AGPL that the evil guys might come up with and, at the other end of
 the spectrum, the most restrictive one?

 AFAIK AGPL hasn't been tested in court, yet.

I continue to believe that the tested in Court standard is highly
overrated.  It's useful, but it's not the litmus test.

The main issue is that very little non-litigation AGPLv3 enforcement has
ever happened, AFAIK.  Status.Net did some on its codebase; I've helped
do some on Pokersource's codebase.  Other than that, I'm not aware
of any.

 But I can't help wondering what people are really scared about here.

I think folks are scared because it's an unknown.  We've lived with
inappropriate GPLv2 aggression from companies like MySQL AB (now Oracle)
for at least a decade now, so we have a good sense of the tricks and
manipulations.

I think AGPLv3 is much better in this regard because it has GPLv3's much
more forgiving Termination provision

 Is it the quine scenario (IMHO ruled out by the license text, but
 obviously you never know...) that people fear to have to implement,
 worrying about the fact that simply providing URLs to tarballs wouldn't
 be considered enough?

... however, admittedly, AGPLv3 is a stronger copyleft than GPLv3
(requiring the thing that Stefano describes), and thus it's easier to
make minor violations, and a company like Oracle might get aggressive.

But, I agree with you Stefano: these worries are speculation based on
past behavior by Oracle, more than they are certainties, which is why I
think the fork-under-AGPLv3 proposal is enough of a hedge to prevent any
serious problems.  But that's a speculative remedy on my part about the
speculative problem herein discussed. :)
-- 
   -- bkuhn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppuyguwu@ebb.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Bradley M. Kuhn

Ondřej Surý wrote at 06:29 (EDT):
 As far as I understand it – there are some parts in Berkeley DB source
 code which is just BSD licensed (and the copyright holders are those
 mentioned earlier)[1], then there are parts which were under SleepyCat
 license and presumably the copyright holder for those parts is Oracle
 – and those were relicensed to AGPLv3. (There are also mixed
 files[3].)

It's probably a good idea for someone to carefully verify these facts.
The community shouldn't assume Oracle got all this right.

 So, the AGPLv3 just needs to be compatible with 3-clause BSD license,
 which is the case.

...which it is, of course.


David Kalnischkies wrote at 17:43 (EDT) on Wednesday:
 So, as I see wrong bits a few times in this thread now: a) APT is
 GPL2+ licensed and will stay that way out of no other choice as I bet
 its more likely that hell freezes over than that we track down every
 contributor since 1997 to ask for an agreement for a license change …

If apt is GPLv2-or-later, you don't need copyright holder permission to
move to GPLv3-or-later, which permits you to combine with AGPLv3'd works
like BDB.

 (yes, we could switch to GPL3+ for free, but it's not like we
 would gain anything from it

That's a matter of debate that I was pointing toward.  It's a policy
decision, and I understand fully why it might not be a good policy
decision for Debian for many reasons, including this one:

  – beside generating problems for GPL2-only dependees on libapt of
  course)

I'm curious, are there many of these?


 On 03/07/13 16:34, Bradley M. Kuhn wrote: [...]
 I know that some have complained that compliance with AGPLv3 may
 require more work by Debian redistributors.  That is a reasonable
 concern, but I think the issue can be mitigated.

MJ Ray wrote at 07:00 (EDT):
 OK, how?

I'm happy to engage in this discussion in detail if Debian decides to
keep the dependency on the AGPLv3'd library.  It sounds like consensus
might be approached that dropping BDB makes the most sense anyway (in
part for technical reasons anyway), so perhaps it will make this
situation moot.


I haven't spent much time helping people make compliance easy for
AGPLv3 -- even though I have some ideas about it -- simply because it's
(sadly) not much of a real-world problem yet, because so few people use
AGPLv3.  As AGPLv3 gets more popular (which I'd love to see), I'm happy
to devote more volunteer time to this to help Debian and others DTRT.

Keep in mind that AGPLv3 is a young license.  We've spent decades
figuring out the proper ways to make GPLv2 compliance easy.  Newer
licenses need just as long to gain good best practices.  It doesn't make
the new license bad, just new.
-- 
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878v1mgupn@ebb.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Florian Weimer

* Stefano Zacchiroli:

 I mean, sure, it *is* more tricky to provide such a URL for users that
 will be running a *modified* version of INN. But it is exactly the same
 kind of difficulties that people distributing modified copylefted
 software will have to face to uphold GPL (or equivalent) terms.

We ship package building software which produces source and binary
packages.  You just copy all of them and are compliant.

We currently do not ship a licensing server that helps users with AGPL
compliance.

My main concern with the license is that compliance is difficult even
for those who have no problem whatsoever with sharing their boring
local changes.  I'm concerned that we're heading to the Linux (kernel)
land where Android and others have made GPL compliance a farce.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4fetfx7@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Bradley M. Kuhn

Ondřej Surý wrote at 00:36 (EDT):
 (d) Is it ok to switch 106 source packages and their reverse depends
 to AGPLv3?

I think that might be stated a bit more clearly: you won't be changing
the license of the upstream works; you'd be changing the license of the
dowstream whole as it appears in Debian.  If the combination is done
during building the software, the license on the source itself doesn't
necessarily change: it's just that the binary is covered by AGPLv3,
which means you have to comply with AGPLv3 with regard to the binary
and its complete, corresponding source (which now includes both BDB
and the upstream sources).

That said, this is indeed an important question to consider, even if I'd
state it differently than Ondřej does.

 1) I think this should be made with consent of upstream authors

In the GPLv2-only and/or AGPLv3-incompatible package cases, you do
indeed need such consent.  In the other cases, you probably don't.

I'd suspect, though, that Debian didn't *add* the BDB dependency to
those packages, but they already had it upstream anyway -- which means
those AGPLv3-incompatible upstream projects are reeling from this action
by Oracle too, and they'll likely independently switch to something
other than BDB anyway, which would solve the problem for Debian without
Debian needing to do any real work other than change some package
configurations.

 2) We need to pick the Berkeley DB version compatible with all
 packages that use the library.

I think this is roughly the same issue as (1), unless you mean a
technical rather than a licensing issue.
-- 
   -- bkuhn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9m2e09x@ebb.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Ondřej Surý

On Thu, Jul 4, 2013 at 6:51 PM, Bradley M. Kuhn bk...@ebb.org wrote:

  2) We need to pick the Berkeley DB version compatible with all
  packages that use the library.

 I think this is roughly the same issue as (1), unless you mean a
 technical rather than a licensing issue.


It is a more technical issue, but based on licensing issue. We need to pick
BDB version with license which is compatible with all packages that uses it.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Vincent Lefevre

On 2013-07-04 15:00:05 +0200, Stefano Zacchiroli wrote:
 On Thu, Jul 04, 2013 at 02:08:33PM +0200, Vincent Lefevre wrote:
  What about users who patch and rebuild software locally?
 
 That was the second paragraph of my post (that you snipped :)), i.e.:
 
  I mean, sure, it *is* more tricky to provide such a URL for users that
  will be running a *modified* version of INN. But it is exactly the
  same kind of difficulties that people distributing modified copylefted
  software will have to face to uphold GPL (or equivalent) terms.

OK, that was unclear. I thought you meant modified by Debian (as
opposed to an unpatched upstream version).

But providing a URL for a user who has few resources (no web site...)
is more difficult than providing the source (in a non-automatic way)
when requested, if this is what you had in mind. At least something
else would need to be done in addition to just patching, rebuilding
and installing the package.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130704214047.ga5...@ioooi.vinc17.net

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-04 Thread Bálint Réczey

2013/7/4 Ondřej Surý ond...@sury.org:

On Thu, Jul 4, 2013 at 6:51 PM, Bradley M. Kuhn bk...@ebb.org wrote:

2) We need to pick the Berkeley DB version compatible with all
packages that use the library.

I think this is roughly the same issue as (1), unless you mean a
technical rather than a licensing issue.

It is a more technical issue, but based on licensing issue. We need to pick
BDB version with license which is compatible with all packages that uses it.
Strictly regarding the technical problem I think Ben's suggestion would work:
2013/7/2 Ben Hutchings b...@decadent.org.uk:
On Tue, 2013-07-02 at 09:35 -0400, Paul Tagliamonte wrote:
On Tue, Jul 02, 2013 at 09:15:15AM -0400, Paul Tagliamonte wrote:
Again, why do you plan on removing free software from main due to a
change in license?

As algernon points out, it makes slightly more sense when you remember
that the AGPLv3 is not compatable with the GPLv2

I'm still against removing it from the archive.

But the new version should not build the default libdb-dev, as that is
likely to result in unintended GPLv2/v3 combinations that cannot be
distributed.

We could keep libdb-dev for the fork keeping the current license and
create a new set of
development packages like libdb6-dev for the AGPLv3 code with or
without switching to an
upstream different from Oracle.

Packages depending on more liberally licensed Berkeley DB won't switch
automatically to
the AGPLv3 this way.

Cheers,
Balint

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cak0odpxntt9luw+ys8s09zd2iv5p33vy_boexdaa3svfin+...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread Ondřej Surý

On Tue, Jul 2, 2013 at 7:11 PM, Andrey Rahmatullin w...@wrar.name wrote:

 On Tue, Jul 02, 2013 at 06:58:34PM +0200, Nick Andrik wrote:
  Since AGPLv3 is really similar to GPLv3 but mostly oriented for
  webapplications, would it make sense to contact Oracle with the
  concerns raised in this thread and ask for clarification and possible
  consideration to change to license to GPLv3 instead?
 
  There could be some possibility that the choice of AGPL over GPL was
  not well considered by their part with all the issues that raises.

 Or, considering the same arguments, to LGPL3+.


They already had a stronger license (SleepyCat is a two-clause BSD with
strong copyleft paragraph added), so it doesn't make any sense to relicense
to LGPLv3+.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread Bradley M. Kuhn

Many people off-list have been asking me to comment on this discussion,
because (like Richard Fontana) I'm a co-author of AGPLv3, and I also
(back in the early 2000's) invented the original licensing idea behind
the AGPLv1.

I thus care deeply about the license and believe it's an important
policy plan for the future of freedom in the age of network services.
(I gave a talk at SCALE 2013 about this specific issue, if folks are
curious about that: https://lwn.net/Articles/541981/ .)

Upon catching up on this thread, I believe most of what needs to be said
about the issue for Debian's perspective has been said.  Nevertheless, I
do want to point out that I think three separate issues have been
conflated in this thread:

  (a) Is the AGPLv3 a DFSG-free license and should it remain such?

  (b) Is it a bad policy decision for Debian generally to have a core
  library, used by many other packages under AGPLv3 -- thus causing
  a move of licensing of more packages toward an effective AGPLv3
  license, due to the combining those packages with an AGPLv3'd
  library.

  (c) Even if (a) and (b) are settled in as Yes, and No,
  respectively: is Oracle, given its history of abusive copyleft
  enforcement (by refusing to allow full compliance as an adequate
  remedy and demanding the purchase of proprietary licenses by
  license violators), too dangerous for Debian and its downstream?

On (a), I think Paul Tagliamonte has summarized the issue best:

Paul Tagliamonte wrote at 09:15 (EDT) on Tuesday:
 The AGPL is a DFSG free FSF approved and OSI approved free software
 license? We made a decision, it's *free software* and fit for main.

I too believe that issue is decided and should be left alone.


On (b), I think the discussion about apt needing to be (effectively)
AGPLv3-or-later to continue using BDB is salient.  I, for one, would
like to see such a thing, but I'm a biased party who co-authored AGPLv3
and believe in its policy goals; I'd like to see more software under
AGPLv3!  But, I also see it from the point of view of Debian developers
who might feel this sort of policy change is too drastic a move to the
strongest copyleft available.

I know that some have complained that compliance with AGPLv3 may require
more work by Debian redistributors.  That is a reasonable concern, but I
think the issue can be mitigated.  The argument is roughly analogous to
this one: complying with GPLv2 is more difficult than complying with the
Apache license.  But, unless Debian wants to take a wholesale position
opposed to copyleft, I don't think this issue is or should be considered
insurmountable.

Indeed, I think that issue is what's being considered in this exchange
between Ondřej and Fontana:

Ondřej Surý wrote at 12:20 (EDT) on Tuesday:
 2. AGPLv3 is incompatible with Apache 2.0 license (http://
 www.apache.org/licenses/GPL-compatibility.html)
Richard Fontana wrote at 13:03 (EDT) on Tuesday:
 Only in the same sense that GPL or LGPL (any version) is
 incompatible with any noncopyleft license in the
 copyleft-to-permissive direction. The Apache License 2.0 is
 compatible with AGPLv3 in the other direction.

I wouldn't frame the debate as Fontana has, but I agree that there's an
issue that copyleft has a certain one-way magnetism to it (by design).
And, the stronger the copyleft, the stronger the magnet.  Once a package
has copylefted parts, the whole package must be considered to be
licensed under the strongest copyleft present.  That may be too big a
leap for apt, but again: that's a policy decision for Debian developers.

Finally, I suggest that the last issue, (c), should be decided
separately from those first two.  Even *if* programs like apt can
reasonably be placed under the AGPLv3, we know that Oracle, per its
MySQL aggression...

Ben Hutchings wrote at 09:48 (EDT) on Tuesday:
 If the relicensing is real and not another misconfiguration of the
 build/release system (like with MySQL docs), this sounds like a
 shakedown for proprietary users of Berkeley DB.  GPLv2-licensed
 users are collateral damage.

... is known to use copyleft licenses as aggressive weapons to force the
sale of proprietary licenses.  Note, however that Sleepycat had roughly
the same business model with its copyleft license hidden behind
BSD-like license drafting.  As such, the only *real* changes I see here
are: (0) an even stronger copyleft is being used and (1) Oracle has a
lot more resources for aggression than Sleepycat did before acquisition.

Admittedly, though, (c) is a very complex policy question, and it's
precisely why I have great trepidation when a codebase is
single-copyright-held by one for-profit company.

BTW, I'd suggest a rather unorthodox solution if developers are
interested: fork this AGPLv3'd version of BDB, and begin making
substantial improvements and changes under AGPLv3.  That way, Oracle
isn't the sole copyright holder, and if Oracle were to take action under
a clause of AGPLv3, other copyright

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread Kelly Clowers

On Tue, Jul 2, 2013 at 10:57 AM, Bernhard R. Link brl...@debian.org wrote:
 * Paul Tagliamonte paul...@debian.org [130702 15:15]:
 Again, why do you plan on removing free software from main due to a
 change in license?

 Licenses matter. Just because something it acceptable for Debian
 main does not mean it is a good idea to have something licensed under
 a specific license. So removing stuff if their license changes can
 make sense in many situations.

 And doubly so for AGPL. (I'll never understand why people consider it
 free software, I'd not even allow the term freeware for it).

Something like AGPL is needed, badly; if you can help come up with a
better license that gets to the same goal, please do!

Cheers,
Kelly Clowers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAFoWM=8cotk4vwjdppg5fqk+7erjfedu3b37sk5no_ppfox...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread David Kalnischkies

On Wed, Jul 3, 2013 at 5:34 PM, Bradley M. Kuhn bk...@ebb.org wrote:
On (b), I think the discussion about apt needing to be (effectively)
AGPLv3-or-later to continue using BDB is salient. I, for one, would
like to see such a thing, but I'm a biased party who co-authored AGPLv3
and believe in its policy goals; I'd like to see more software under
AGPLv3! But, I also see it from the point of view of Debian developers
who might feel this sort of policy change is too drastic a move to the
strongest copyleft available.

So, as I see wrong bits a few times in this thread now:
a) APT is GPL2+ licensed and will stay that way out of no other choice as
I bet its more likely that hell freezes over than that we track down every
contributor since 1997 to ask for an agreement for a license change …
(yes, we could switch to GPL3+ for free, but it's not like we would gain
anything from it – beside generating problems for GPL2-only dependees on
libapt of course)
b) src:apt depends on libdb-dev for apt-ftparchive which is shipped in
apt-utils. I doubt it is insanely hard to switch to another database if
we would need to – the database is used as a cache, so not even strictly
needed – but GPL2+ is compatible with AGPL so I don't see why.
(Also, you can't interact with apt-ftparchive over the network,
so no practical difference)
Other parts of APT have no relation to libdb whatsoever.

Sidenote: Debian infrastructure (aka dak) isn't depending on apt-ftparchive
anymore [just some derivatives use it nowadays], so the binary is even
less important than you might think/remember.

Disclaimer: This is not a remark regarding AGPL.
I am just trying to correct misunderstandings in regards to APT.

Best regards

David Kalnischkies

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fcfhgmkmx6a4hdvv5ysp_+siyqwfn7gdfk+j3bmbcv...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread Michael Banck

Hi,

On Tue, Jul 02, 2013 at 02:48:18PM +0100, Ben Hutchings wrote:
 If the relicensing is real and not another misconfiguration of the
 build/release system (like with MySQL docs), this sounds like a
 shakedown for proprietary users of Berkeley DB.  GPLv2-licensed users
 are collateral damage.

People have pointed out upthread that Oracle does not appear to be the
sole copyright holder of BerkelyDB.  So unless they had copyright
assignments or similar on file, maybe a viable route would be to contact
those additional copyright holders and suggest they complain to Oracle
in order to get their relicensing reversed.

This should probably be done in coordination with the wider Free
Software community.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130703222716.gf27...@nighthawk.chemicalconnection.dyndns.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread Ondřej Surý

On Thu, Jul 4, 2013 at 12:27 AM, Michael Banck mba...@debian.org wrote:

 Hi,

 On Tue, Jul 02, 2013 at 02:48:18PM +0100, Ben Hutchings wrote:
  If the relicensing is real and not another misconfiguration of the
  build/release system (like with MySQL docs), this sounds like a
  shakedown for proprietary users of Berkeley DB.  GPLv2-licensed users
  are collateral damage.

 People have pointed out upthread that Oracle does not appear to be the
 sole copyright holder of BerkelyDB.  So unless they had copyright
 assignments or similar on file, maybe a viable route would be to contact
 those additional copyright holders and suggest they complain to Oracle
 in order to get their relicensing reversed.

 This should probably be done in coordination with the wider Free
 Software community.


From my understanding, the other copyright holders' opinion doesn't really
matter – even if they relicense just the parts they own the whole work will
be distributed under stricter license (e.g. AGPLv3). But feel free to
correct me if I am wrong.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-03 Thread Ondřej Surý

Bradley,

On Wed, Jul 3, 2013 at 5:34 PM, Bradley M. Kuhn bk...@ebb.org wrote:

 [...]
 Upon catching up on this thread, I believe most of what needs to be said
 about the issue for Debian's perspective has been said.  Nevertheless, I
 do want to point out that I think three separate issues have been
 conflated in this thread:

   (a) Is the AGPLv3 a DFSG-free license and should it remain such?

   (b) Is it a bad policy decision for Debian generally to have a core
   library, used by many other packages under AGPLv3 -- thus causing
   a move of licensing of more packages toward an effective AGPLv3
   license, due to the combining those packages with an AGPLv3'd
   library.

   (c) Even if (a) and (b) are settled in as Yes, and No,
   respectively: is Oracle, given its history of abusive copyleft
   enforcement (by refusing to allow full compliance as an adequate
   remedy and demanding the purchase of proprietary licenses by
   license violators), too dangerous for Debian and its downstream?

[...]

I don't think that neither (a) nor (b) is the core issue here.

I might have missed one important point in my first email. We want to keep
just one (default) Berkeley DB version in each Debian release for practical
reasons (maintainers sanity, mutual compatibility, etc.). So, you need to
view the issue from a perspective of picking just one Berkeley DB version.

I think the core issue apart from (c) is:

(d) Is it ok to switch 106 source packages and their reverse depends to
AGPLv3?

And the answer here is clearly No for two reasons.

1) I think this should be made with consent of upstream authors
2) We need to pick the Berkeley DB version compatible with all packages
that use the library.

And from quick scan of
http://ftp-master.metadata.debian.org/changelogs/main/$L/$P/unstable_copyright
:

389-ds-base: GPLv2-only
apr-util: Apache 2.0
boxbackup: 4-clause BSD
canl-c++: Apache 2.0
clisp: GPLv2-only
cyrus-imapd-2.4: 4-clause BSD
cyrus-sasl2: 4-clause BSD
dovecot (parts): 4-clause BSD
evolution-exchange: GPLv2-only
exim: sasl parts are 4-clause BSD[1]
gqcov: GPLv2-only
gridengine: tcsh parts under 4-clause BSD, rest is SISSL[2]
hpsockd: GPLv2-only
iproute2: GPLv2-only
jabberd2: GPLv2-only
jigdo: GPLv2-only
kamailio: OpenSSL parts with advertising clause
ldiskfsprogs: GPLv2-only
libqxt: contains file with LGPL2.1-only
lucene2: Apache 2.0
moc: GPLv2-only
netatalk: GPLv2-only file[3]
nordugrid-arc: Apache 2.0
nvi: 4-clause BSD
pavuk: advertising clause
php5: PHP License 3.01[4]
postfix: IBM PUBLIC LICENSE 1.0[5]
prayer: cyrus-imap parts under 4-clause BSD
radiusd-livingston: 4-clause BSD
redland: Apache 2.0
reprepro: GPLv2-only
rpm: lib/merge.c is 4-clause BSD[1]
spamprobe: QPL[6]
squidguard: GPLv2-only
subversion: Apache 2.0
wvstreams: LGPLv2.1-only
zeroc-ice: GPLv2-only

This list is by no means complete or 100% correct. There might be
oversights and/or bugs in debian/copyrights (BTW the machine readable
copyrights would help here).

All those listed packages would have to stop using Berkeley DB (or
relicense) before we could make the switch to Berkeley DB 6.0. The rest of
the packages (especially the networked ones) would have to comply with
AGPLv3 before we could make the switch to default Berkeley DB 6.0.
(
This applies also for all the packages further down the tree (e.g. libsasl2
users if we keep the sasldb plugin[7])

1. BTW this links 4-clause BSD with GPL code within the same source
2. SISSL is not GPL compatible according to Wikipedia
3. And a couple of files under UNKNOWN license :)
4. AFAIK GPL-incompatible
5. http://www.gnu.org/licenses/license-list.html#IBMPL
6. http://www.gnu.org/licenses/license-list.html#QPL
7. However this case might be the borderline case as outlined here:
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Paul Tagliamonte

On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
 Florian Weimer has correctly pointed out that Oracle has decided to change the
 BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
 56.html). This hasn't been reflected in release tarball (probably by
 mistake), but since the AGPLv3 is not very friendly to downstream projects, we
 (as the Debian project) need to take a decision.

What? Wait, What? What?[1]

The AGPL is a DFSG free FSF approved and OSI approved free software
license? We made a decision, it's *free software* and fit for main.

 My opinion is that this Oracle move just sent the Berkeley DB to oblivion, and
 Berkeley DB will be less and less used (or replaced by something else).

Sure. Software comes and goes. Why not let it happen, who cares, it's
still free software.

 What we can do right now (more can apply):
 [ ] Keep db5.3 for jessie
 [ ] Keep db5.3 for jessie+
 [ ] Keep db5.3 forever
 [ ] Suck it and relicense the downstream software as appropriate
 [ ] Block db6.0 and higher from entering Debian
 [ ] Remove Berkeley DB support from jessie+
 [ ] Remove Berkeley DB support from jessie++
 [ ] Replace Berkeley DB with free alternative [*]
 [ ] Somebody writes a BDB-compatible wrapper around the free alternative(s)
  [ ] Do nothing because it's free software

 dak rm -Rn -s unstable db-defaults db5.1 db5.3  db-depends

Again, why do you plan on removing free software from main due to a
change in license?

Cheers,
  Paul


[1]: 
http://1.bp.blogspot.com/-GfEnd4xeEJs/UOxBvCCdgGI/BSU/PgL41SlEQ98/s1600/huh-what.gif

-- 
 .''`.  Paul Tagliamonte paul...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Paul Tagliamonte

On Tue, Jul 02, 2013 at 09:15:15AM -0400, Paul Tagliamonte wrote:
 Again, why do you plan on removing free software from main due to a
 change in license?

As algernon points out, it makes slightly more sense when you remember
that the AGPLv3 is not compatable with the GPLv2

I'm still against removing it from the archive.

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte paul...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

On Tue, Jul 2, 2013 at 3:15 PM, Paul Tagliamonte paul...@debian.org wrote:

 On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
  Florian Weimer has correctly pointed out that Oracle has decided to
 change the
  BDB 6.0 license to AGPLv3 (
 https://oss.oracle.com/pipermail/bdb/2013-June/
  56.html). This hasn't been reflected in release tarball (probably by
  mistake), but since the AGPLv3 is not very friendly to downstream
 projects, we
  (as the Debian project) need to take a decision.

 What? Wait, What? What?[1]

 The AGPL is a DFSG free FSF approved and OSI approved free software
 license? We made a decision, it's *free software* and fit for main.


apt-get is licensed GPLv2 and thus incompatible with AGPLv3.
cyrus-{imapd,sasl} has BSD-style license and thus incompatible with AGPLv3.
OpenLDAP has BSD-style (OpenLDAP) license and thus incompatible with AGPLv3.
subversion has Apache 2.0 license and thus incompatible with AGPLv3.

...do I have to even continue...?


  My opinion is that this Oracle move just sent the Berkeley DB to
 oblivion, and
  Berkeley DB will be less and less used (or replaced by something else).

 Sure. Software comes and goes. Why not let it happen, who cares, it's
 still free software.


I guess the maintainers of r-depends _care_!


   What we can do right now (more can apply):
  [ ] Keep db5.3 for jessie
  [ ] Keep db5.3 for jessie+
  [ ] Keep db5.3 forever
  [ ] Suck it and relicense the downstream software as appropriate
  [ ] Block db6.0 and higher from entering Debian
  [ ] Remove Berkeley DB support from jessie+
  [ ] Remove Berkeley DB support from jessie++
  [ ] Replace Berkeley DB with free alternative [*]
  [ ] Somebody writes a BDB-compatible wrapper around the free
 alternative(s)
   [ ] Do nothing because it's free software

  dak rm -Rn -s unstable db-defaults db5.1 db5.3  db-depends

 Again, why do you plan on removing free software from main due to a
 change in license?


I am not removing anything, have you read my email? This command was merely
used to generate list of r-depends of Berkeley DB.

But we cannot maintain db5.3 (or db5.1) forever if upstream declares it
dead.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Ben Hutchings

On Tue, 2013-07-02 at 09:35 -0400, Paul Tagliamonte wrote:
 On Tue, Jul 02, 2013 at 09:15:15AM -0400, Paul Tagliamonte wrote:
  Again, why do you plan on removing free software from main due to a
  change in license?
 
 As algernon points out, it makes slightly more sense when you remember
 that the AGPLv3 is not compatable with the GPLv2
 
 I'm still against removing it from the archive.

But the new version should not build the default libdb-dev, as that is
likely to result in unintended GPLv2/v3 combinations that cannot be
distributed.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


signature.asc
Description: This is a digitally signed message part

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Tollef Fog Heen

]] Paul Tagliamonte 

 On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
  Florian Weimer has correctly pointed out that Oracle has decided to change 
  the
  BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
  56.html). This hasn't been reflected in release tarball (probably by
  mistake), but since the AGPLv3 is not very friendly to downstream projects, 
  we
  (as the Debian project) need to take a decision.
 
 What? Wait, What? What?[1]
 
 The AGPL is a DFSG free FSF approved and OSI approved free software
 license? We made a decision, it's *free software* and fit for main.

An AGPL licenced libdb isn't particularly useful for us, though.  It'd
mean distributing a fair amount of software including exim, postfix,
squid, webalizer, dovecot and many other servers under the AGPL, which
would mean patching them so you could download the source code through
them.

AGPL is a sometimes usable licence for webapps.  It's completely
unusable for a library like libdb.

I think we should just keep libdb5.3 until a suitable replacement shows
up.

 Again, why do you plan on removing free software from main due to a
 change in license?

I don't think he's suggested removing it?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4fh9j2w@xoog.err.no

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Ben Hutchings

On Tue, 2013-07-02 at 09:44 +0200, Ondřej Surý wrote:
 Hi,
 
 Florian Weimer has correctly pointed out that Oracle has decided to
 change the BDB 6.0 license to AGPLv3
 (https://oss.oracle.com/pipermail/bdb/2013-June/56.html). This
 hasn't been reflected in release tarball (probably by mistake), but
 since the AGPLv3 is not very friendly to downstream projects, we (as
 the Debian project) need to take a decision.

 My opinion is that this Oracle move just sent the Berkeley DB to
 oblivion, and Berkeley DB will be less and less used (or replaced by
 something else).

If the relicensing is real and not another misconfiguration of the
build/release system (like with MySQL docs), this sounds like a
shakedown for proprietary users of Berkeley DB.  GPLv2-licensed users
are collateral damage.

 What we can do right now (more can apply):
[...]
 [ ] Keep db5.3 forever

Well, indefinitely.  But I somewhat expect some BSD developers to try
maintaining a fork of it, as they're very unlikely to be happy with
AGPLv3.

 [ ] Suck it and relicense the downstream software as appropriate
[...]

GPLv3 is compatible with almost all common licences except GPLv2 (though
that might not be true with the additional conditions of AGPLv3).  If
anyone has made a decision to use GPLv2-only then I wouldn't expect them
to relicense for this.  Therefore a BSD-licensed libdb is still needed.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


signature.asc
Description: This is a digitally signed message part

Re: Berkeley DB 6.0 license change to AGPLv3

On Tue, Jul 2, 2013 at 3:39 PM, Tollef Fog Heen tfh...@err.no wrote:

 I think we should just keep libdb5.3 until a suitable replacement shows
 up.


The OpenLDAP lightningdb might be a viable option: http://symas.com/mdb/

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Dan Shearer

On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:

 Florian Weimer has correctly pointed out that Oracle has decided to change
 the BDB 6.0 license to AGPLv3 (
 https://oss.oracle.com/pipermail/bdb/2013-June/56.html).
   :
 we (as the Debian project) need to take a decision.
   :

(because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
and there is code under these licenses which depends on BDB. There is
also code which depends on BDB that is compatible with the AGPLv3
legally, but whose deployment would then be restricted in ways the users
would not be expecting.)

 As far as I am aware the most prominent users of Berkeley DB are
 moving away from the library anyway ...

There are actually very few true alternatives to BDB. While there are
many KVP (key value pair) stores [1] not many are transactional, allow
multi-version concurrency control [2] and support multi-threaded and
multi-process access. BDB is all of the above, and in addition the BDB
API has become very widely used over nearly 30 years. And of course the
BSD license allowed BDB to be embedded in a huge amount of software - 
like the BSD networking stack, it turns up just about everywhere.

So there are three things to think about in a replacement:

1. Is the licensing as suitable as the BSD license has been, and is 
the primary maintainer likely to do what Oracle just did to BDB?

2. Are the features at least as good as BDB, and is the API close enough
to make replacement reasonably easy?

3. BDB is very old code. When replacing it can we also adopt modern
approaches more suited to modern hardware and use cases?

I've looked at all of the KVP options I am aware of and consulted people
who specialise in the space and can only see one that fits each of these
well. MDB from the OpenLDAP project, http://symas.com/mdb/ .

As to point 1, the rights holders of MDB need to make a public
statement, but I have asked them in private and in any case the OpenLDAP
history speaks for itself.

As to point 2, MDB provides a superset of the KVP-specific features of
BDB, and the API is similar to BDB but somewhat simpler.

As to point 3, MDB is a from-scratch implementation in the modern world.
MDB object code is a tiny fraction of BDB, and by adopting a
memory-mapped architecture and dispensing with caching and locking it
relies on modern operating system features rather than trying to
implement them internally. This means greatly increased performance and
very much smaller windows for corruption to occur. MDB has very clean
support for concurrency compared to BDB, which makes it much more
suitable for modern applications. 

There is an technical discussion of MDB here:
http://symas.com/mdb/20120829-LinuxCon-MDB-txt.pdf . Some performance
data has been published, one simple test that has a minimum of
imaginable bias is to compare the SQLite3 API that comes with Oracle BDB
with the SQLite3 ported to MDB. The other obvious speed test (that has
had reproducible data published) is with OpenLDAP, which has pluggable
back ends including both BDB and MDB.

I'll be delighted if someone can suggest something that is even more
suitable than MDB, but so far I haven't seen it.

Looking at the Debian archive, packages with BDB dependencies are as
follows (MDB integration has been marked where it exists, currently
about 10% of the packages.):

389-ds-base
animals
apr-util
apt
bind9
bitcoin
bmf
bogofilter
boxbackup
cairo-dock-plug-ins
canl-c++
cfengine2
cfengine3LMDB support published
chise-base
c-icap
citadel
claws-mail
clisp
cyrus-imapd-2.4
cyrus-sasl2 LMDB support published
db-defaults
dnshistory
dovecot
drac
dsniff
evolution-data-server
evolution-exchange
exim4
fsvs
ggcov
glusterfs
gridengine
guile-db
heimdal LMDB supported
hotkeys
hpsockd
inn2
iproute
iproute2
isync
jabberd2
libetpan
libnss-db
libpam-abl
libpam-ccreds
libpinyin
libqxt
librcc
lucene2
mailavenger
memcachedb  LMDB support published
mit-scheme
mmorph
moc
netatalk
nmh
nordugrid-arc
nss-updatedb
nvi
onak
open-cobol
opendkimLMDB supported
openldapLMDB supported
pam
pavuk
perdition
perl
php5
poedit
postfix LMDB support published
prayer
python2.7   LMDB supported
python3.2   LMDB supported
python3.3   LMDB supported
python-bsddb3
radiusd-livingston
redland
reprepro
resiprocate
rhmessaging
rpm
ruby-bdbLMDB supported
sendmail
skksearch
skktools
sks
spamprobe
squid
squid3
squidguard
subversion
syrep
tcpstat
torrus
trustedqsl
vacation
webalizer
webdruid
wvstreams
xastir
xemacs21
zeroc-ice


HtH,

--
Dan Shearer
d...@shearer.org



[1] KVP: Key value pair store

Re: Berkeley DB 6.0 license change to AGPLv3

Thanks Dan for this comprehensive email.

I'll take ITP bug for libmdb (#694757) under pkg-db umbrella, as it will
affect Berkeley DB, so it makes sense to have it there.

People are most welcome to join the team, as I am the only active person in
the team.

O.


On Tue, Jul 2, 2013 at 4:38 PM, Dan Shearer d...@shearer.org wrote:

 On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:

  Florian Weimer has correctly pointed out that Oracle has decided to
 change
  the BDB 6.0 license to AGPLv3 (
  https://oss.oracle.com/pipermail/bdb/2013-June/56.html).
:
  we (as the Debian project) need to take a decision.
:

 (because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
 and there is code under these licenses which depends on BDB. There is
 also code which depends on BDB that is compatible with the AGPLv3
 legally, but whose deployment would then be restricted in ways the users
 would not be expecting.)

  As far as I am aware the most prominent users of Berkeley DB are
  moving away from the library anyway ...

 There are actually very few true alternatives to BDB. While there are
 many KVP (key value pair) stores [1] not many are transactional, allow
 multi-version concurrency control [2] and support multi-threaded and
 multi-process access. BDB is all of the above, and in addition the BDB
 API has become very widely used over nearly 30 years. And of course the
 BSD license allowed BDB to be embedded in a huge amount of software -
 like the BSD networking stack, it turns up just about everywhere.

 So there are three things to think about in a replacement:

 1. Is the licensing as suitable as the BSD license has been, and is
 the primary maintainer likely to do what Oracle just did to BDB?

 2. Are the features at least as good as BDB, and is the API close enough
 to make replacement reasonably easy?

 3. BDB is very old code. When replacing it can we also adopt modern
 approaches more suited to modern hardware and use cases?

 I've looked at all of the KVP options I am aware of and consulted people
 who specialise in the space and can only see one that fits each of these
 well. MDB from the OpenLDAP project, http://symas.com/mdb/ .

 As to point 1, the rights holders of MDB need to make a public
 statement, but I have asked them in private and in any case the OpenLDAP
 history speaks for itself.

 As to point 2, MDB provides a superset of the KVP-specific features of
 BDB, and the API is similar to BDB but somewhat simpler.

 As to point 3, MDB is a from-scratch implementation in the modern world.
 MDB object code is a tiny fraction of BDB, and by adopting a
 memory-mapped architecture and dispensing with caching and locking it
 relies on modern operating system features rather than trying to
 implement them internally. This means greatly increased performance and
 very much smaller windows for corruption to occur. MDB has very clean
 support for concurrency compared to BDB, which makes it much more
 suitable for modern applications.

 There is an technical discussion of MDB here:
 http://symas.com/mdb/20120829-LinuxCon-MDB-txt.pdf . Some performance
 data has been published, one simple test that has a minimum of
 imaginable bias is to compare the SQLite3 API that comes with Oracle BDB
 with the SQLite3 ported to MDB. The other obvious speed test (that has
 had reproducible data published) is with OpenLDAP, which has pluggable
 back ends including both BDB and MDB.

 I'll be delighted if someone can suggest something that is even more
 suitable than MDB, but so far I haven't seen it.

 Looking at the Debian archive, packages with BDB dependencies are as
 follows (MDB integration has been marked where it exists, currently
 about 10% of the packages.):

 389-ds-base
 animals
 apr-util
 apt
 bind9
 bitcoin
 bmf
 bogofilter
 boxbackup
 cairo-dock-plug-ins
 canl-c++
 cfengine2
 cfengine3LMDB support published
 chise-base
 c-icap
 citadel
 claws-mail
 clisp
 cyrus-imapd-2.4
 cyrus-sasl2 LMDB support published
 db-defaults
 dnshistory
 dovecot
 drac
 dsniff
 evolution-data-server
 evolution-exchange
 exim4
 fsvs
 ggcov
 glusterfs
 gridengine
 guile-db
 heimdal LMDB supported
 hotkeys
 hpsockd
 inn2
 iproute
 iproute2
 isync
 jabberd2
 libetpan
 libnss-db
 libpam-abl
 libpam-ccreds
 libpinyin
 libqxt
 librcc
 lucene2
 mailavenger
 memcachedb  LMDB support published
 mit-scheme
 mmorph
 moc
 netatalk
 nmh
 nordugrid-arc
 nss-updatedb
 nvi
 onak
 open-cobol
 opendkimLMDB supported
 openldapLMDB supported
 pam
 pavuk
 perdition
 perl
 php5
 poedit
 postfix LMDB support published
 prayer
 python2.7   LMDB supported
 python3.2   LMDB supported
 python3.3   LMDB supported

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Clint Adams

On Tue, Jul 02, 2013 at 03:36:57PM +0200, Ondřej Surý wrote:
 apt-get is licensed GPLv2 and thus incompatible with AGPLv3.

No, apt is GPL-2+.

 cyrus-{imapd,sasl} has BSD-style license and thus incompatible with AGPLv3.
 OpenLDAP has BSD-style (OpenLDAP) license and thus incompatible with AGPLv3.
 subversion has Apache 2.0 license and thus incompatible with AGPLv3.

I think you are misunderstanding the AGPL.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702145732.ga15...@scru.org

Re: Berkeley DB 6.0 license change to AGPLv3

(Written on my phone).

I have worked with original information from Florian's follow-up to transition 
bug. Sorry for not checking apt license myself. Anyway... effectivelly 
relicensing apt to GPL-3 might not be a problem for apt (and all its rev-deps), 
but it is a still problem for all other software under other licenses.

Changing BSD-style license (with open the source clause) to (A)GPL-3 for a 
widely used library is a problem. There's no misunderstanding here.

Also it would cultivate the debate here if you have presented your arguments 
(e.g. explain why I might be mistaken) instead of presenting just the ad 
hominem arguments. Thanks.

Ondřej Surý

 On 2. 7. 2013, at 16:57, Clint Adams cl...@debian.org wrote:
 
 On Tue, Jul 02, 2013 at 03:36:57PM +0200, Ondřej Surý wrote:
 apt-get is licensed GPLv2 and thus incompatible with AGPLv3.
 
 No, apt is GPL-2+.
 
 cyrus-{imapd,sasl} has BSD-style license and thus incompatible with AGPLv3.
 OpenLDAP has BSD-style (OpenLDAP) license and thus incompatible with AGPLv3.
 subversion has Apache 2.0 license and thus incompatible with AGPLv3.
 
 I think you are misunderstanding the AGPL.
 
 
 -- 
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20130702145732.ga15...@scru.org
 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/c8c9196b-b771-4d0e-bf9f-07474910b...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Clint Adams

On Tue, Jul 02, 2013 at 05:22:03PM +0200, Ondřej Surý wrote:
 Also it would cultivate the debate here if you have presented your arguments 
 (e.g. explain why I might be mistaken) instead of presenting just the ad 
 hominem arguments. Thanks.

I am not a lawyer, though I work for lawyers.  It would be
irresponsible for me to present such arguments.

I can suggest, however, that you can either read the license text
or contact licens...@fsf.org before spreading more FUD.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702153039.ga16...@scru.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Joey Hess

Tollef Fog Heen wrote:
 An AGPL licenced libdb isn't particularly useful for us, though.  It'd
 mean distributing a fair amount of software including exim, postfix,
 squid, webalizer, dovecot and many other servers under the AGPL, which
 would mean patching them so you could download the source code through
 them.

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.

It's probably a stretch to claim that users interact with exim, postfix and
dovecot over the network. In any case, the AGPL does not require that the
program be a quine; it'd certainly be acceptable for a comment to be output
over SMTP (for example) with an URL to download the source.

 I think we should just keep libdb5.3 until a suitable replacement shows
 up.

I assume this is going to be dealt with upstream in each affected peice of
software. The only risk seems to be if an upstream upgrades without being
aware of the license change.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Russ Allbery

Joey Hess jo...@debian.org writes:

 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.

 It's probably a stretch to claim that users interact with exim, postfix
 and dovecot over the network.

It would be useful to have some clarification of exactly what Oracle means
by that.  (The FSF's opinion isn't horribly useful given that they're not
the copyright holders, even if they're the original authors of the
license.)

 In any case, the AGPL does not require that the program be a quine; it'd
 certainly be acceptable for a comment to be output over SMTP (for
 example) with an URL to download the source.

As an upstream for INN, I think doing such a thing would be completely
absurd, and would rather just drop Berkeley DB support entirely and make
everyone switch to a different overview method than do anything of the
sort.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvvxj5rq@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

On Tue, Jul 2, 2013 at 5:30 PM, Clint Adams cl...@debian.org wrote:

 On Tue, Jul 02, 2013 at 05:22:03PM +0200, Ondřej Surý wrote:
  Also it would cultivate the debate here if you have presented your
 arguments (e.g. explain why I might be mistaken) instead of presenting just
 the ad hominem arguments. Thanks.

 I am not a lawyer, though I work for lawyers.  It would be
 irresponsible for me to present such arguments.


While flushing all said with 'you misunderstand AGPL' is a responsible
thing to do.


 I can suggest, however, that you can either read the license text
 or contact licens...@fsf.org before spreading more FUD.


I don't believe I have spread any FUD.

1. AGPLv3 is incompatible with GPLv2-only (
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
2. AGPLv3 is incompatible with Apache 2.0 license (
http://www.apache.org/licenses/GPL-compatibility.html)
3. AGPLv3 is more restrictive thus distributing the derivate works must be
licensed under AGPLv3 (e.g. GPL is hereditary) (f.e.
http://www.gnu.org/licenses/lgpl-java.html)

So a move from SleepyCat license to GPL based one is in fact problematic
and cannot be done lightly (and without upstream software author consent).

Ondrej
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

On Tue, Jul 2, 2013 at 6:20 PM, Ondřej Surý ond...@sury.org wrote:

 On Tue, Jul 2, 2013 at 5:30 PM, Clint Adams cl...@debian.org wrote:

 On Tue, Jul 02, 2013 at 05:22:03PM +0200, Ondřej Surý wrote:
  Also it would cultivate the debate here if you have presented your
 arguments (e.g. explain why I might be mistaken) instead of presenting just
 the ad hominem arguments. Thanks.

 I am not a lawyer, though I work for lawyers.  It would be
 irresponsible for me to present such arguments.


 While flushing all said with 'you misunderstand AGPL' is a responsible
 thing to do.


 I can suggest, however, that you can either read the license text
 or contact licens...@fsf.org before spreading more FUD.


 I don't believe I have spread any FUD.

 1. AGPLv3 is incompatible with GPLv2-only (
 http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
 2. AGPLv3 is incompatible with Apache 2.0 license (
 http://www.apache.org/licenses/GPL-compatibility.html)
  3. AGPLv3 is more restrictive thus distributing the derivate works must
 be licensed under AGPLv3 (e.g. GPL is hereditary) (f.e.
 http://www.gnu.org/licenses/lgpl-java.html)

 So a move from SleepyCat license to GPL based one is in fact problematic
 and cannot be done lightly (and without upstream software author consent).


Just to clarify – I am not in any way opposed to the hereditary properties
of (A)GPL. The evil thing is the relicensing at the point where people
depend on you, and not the license itself.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

* Paul Tagliamonte:

 On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
 Florian Weimer has correctly pointed out that Oracle has decided to change 
 the
 BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
 56.html). This hasn't been reflected in release tarball (probably by
 mistake), but since the AGPLv3 is not very friendly to downstream projects, 
 we
 (as the Debian project) need to take a decision.

 What? Wait, What? What?[1]

 The AGPL is a DFSG free FSF approved and OSI approved free software
 license? We made a decision, it's *free software* and fit for main.

The problems start when random, network-enabled, but non-web stuff
switches over to the AGPL *without* implementing the Quine required by
the license (which is somewhat difficult to do for a library, but at
least there could be a give me a tarball interface).  That makes it
difficult to perform local changes and stay in compliance with the
license because you have to build the source code distribution
mechanism from scratch and design a process that ensures the sources
and running binaries match at all times.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obak5310@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Russ Allbery

Ondřej Surý ond...@sury.org writes:

 Just to clarify – I am not in any way opposed to the hereditary
 properties of (A)GPL. The evil thing is the relicensing at the point
 where people depend on you, and not the license itself.

I don't believe the AGPL was ever intended to be used for libraries.
Quite a bit of the license is very difficult to interpret as applied to a
library.  (For example, does that mean that every application using the
library has to provide a URL to download the source of the *library*?  Is
the user interacting with the library directly over the network?)

I think this one is all on Oracle.  They're using a license that was never
intended for a basic infrastructure library, quite possibly in an attempt
to make it obnoxious and excessively onerous to use the open source
version, or to create a situation where nearly all users of their library
are violating some technical term of the license (or at least are close
enough that a lawsuit wouldn't be immediately thrown out) and therefore
can be shaken down for cash if Oracle feels like it.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y59oj4ld@windlord.stanford.edu

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Nick Andrik

2013/7/2 Russ Allbery r...@debian.org:
I don't believe the AGPL was ever intended to be used for libraries.
Quite a bit of the license is very difficult to interpret as applied to a
library. (For example, does that mean that every application using the
library has to provide a URL to download the source of the *library*? Is
the user interacting with the library directly over the network?)

I think this one is all on Oracle. They're using a license that was never
intended for a basic infrastructure library, quite possibly in an attempt
to make it obnoxious and excessively onerous to use the open source
version, or to create a situation where nearly all users of their library
are violating some technical term of the license (or at least are close
enough that a lawsuit wouldn't be immediately thrown out) and therefore
can be shaken down for cash if Oracle feels like it.

Since AGPLv3 is really similar to GPLv3 but mostly oriented for
webapplications, would it make sense to contact Oracle with the
concerns raised in this thread and ask for clarification and possible
consideration to change to license to GPLv3 instead?

There could be some possibility that the choice of AGPL over GPL was
not well considered by their part with all the issues that raises.

On the other hand, with Oracle one can never be sure, but at least
contacting them will make the problem more widely apparent and their
ittentions more clear.

--
=Do-
N.AND

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANn5kOuWyfPjtyPa-Gqdis9Pv1ub73fW=6353zufwbg1fgx...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Dmitrijs Ledkovs

On 2 July 2013 17:58, Nick Andrik nick.and...@gmail.com wrote:
2013/7/2 Russ Allbery r...@debian.org:
I don't believe the AGPL was ever intended to be used for libraries.
Quite a bit of the license is very difficult to interpret as applied to a
library. (For example, does that mean that every application using the
library has to provide a URL to download the source of the *library*? Is
the user interacting with the library directly over the network?)

There could be some possibility that the choice of AGPL over GPL was
not well considered by their part with all the issues that raises.

On the other hand, with Oracle one can never be sure, but at least
contacting them will make the problem more widely apparent and their
ittentions more clear.

Looking at db5.3 copyright file, I see copyright holders:
INRIA, France Telecom
The President and Fellows of Harvard University
The Regents of the University of California
Oracle

So is the whole code base re-licensed? or only the changes that Orcale
is making here-after?

Regards,

Dmitrijs.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/canbhluiok18hp34xbvp+t9gq+p9n3yrzgee7o1+icruv4pk...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

On Tue, Jul 2, 2013 at 6:58 PM, Nick Andrik nick.and...@gmail.com wrote:

 2013/7/2 Russ Allbery r...@debian.org:
  I don't believe the AGPL was ever intended to be used for libraries.
  Quite a bit of the license is very difficult to interpret as applied to a
  library.  (For example, does that mean that every application using the
  library has to provide a URL to download the source of the *library*?  Is
  the user interacting with the library directly over the network?)
 
  I think this one is all on Oracle.  They're using a license that was
 never
  intended for a basic infrastructure library, quite possibly in an attempt
  to make it obnoxious and excessively onerous to use the open source
  version, or to create a situation where nearly all users of their library
  are violating some technical term of the license (or at least are close
  enough that a lawsuit wouldn't be immediately thrown out) and therefore
  can be shaken down for cash if Oracle feels like it.

 Since AGPLv3 is really similar to GPLv3 but mostly oriented for
 webapplications, would it make sense to contact Oracle with the
 concerns raised in this thread and ask for clarification and possible
 consideration to change to license to GPLv3 instead?


That would help just a little bit. GPLv3 library is still incompatible with
f.e. Apache 2.0 licensed program.

So this would still need to be handled in case-by-case manner working
closely with upstream developers.

There could be some possibility that the choice of AGPL over GPL was
 not well considered by their part with all the issues that raises.

 On the other hand, with Oracle one can never be sure, but at least
 contacting them will make the problem more widely apparent and their
 ittentions more clear.


I already wrote to the Oracle developer I am in close contact with about
the mismatch of the license in distribution tarball and I will pursue this
further when he responds.

Ondrej
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Julien Cristau

On Tue, Jul  2, 2013 at 18:58:34 +0200, Nick Andrik wrote:

 Since AGPLv3 is really similar to GPLv3 but mostly oriented for
 webapplications, would it make sense to contact Oracle with the
 concerns raised in this thread and ask for clarification and possible
 consideration to change to license to GPLv3 instead?
 
GPLv3 would be just as bad.  Changing a library from BSD to GPL is
something you just don't do.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Andrey Rahmatullin

On Tue, Jul 02, 2013 at 06:58:34PM +0200, Nick Andrik wrote:
 Since AGPLv3 is really similar to GPLv3 but mostly oriented for
 webapplications, would it make sense to contact Oracle with the
 concerns raised in this thread and ask for clarification and possible
 consideration to change to license to GPLv3 instead?
 
 There could be some possibility that the choice of AGPL over GPL was
 not well considered by their part with all the issues that raises.

Or, considering the same arguments, to LGPL3+.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

On Tue, Jul 2, 2013 at 7:03 PM, Richard Fontana rfont...@redhat.com wrote:

 On Tue, Jul 02, 2013 at 06:20:48PM +0200, Ondřej Surý wrote:
  I don't believe I have spread any FUD.
 
 [...]
  2. AGPLv3 is incompatible with Apache 2.0 license (
 http://www.apache.org/
  licenses/GPL-compatibility.html)

 Only in the same sense that GPL or LGPL (any version) is incompatible
 with any noncopyleft license in the copyleft-to-permissive
 direction. The Apache License 2.0 is compatible with AGPLv3 in the
 other direction.


Yeah, but we are talking about a library here, so it's the wrong direction
case here.  But right, I should have been more clear here.

O.
-- 
Ondřej Surý ond...@sury.org

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Francesco Poli

On Tue, 02 Jul 2013 18:40:11 +0200 Florian Weimer wrote:

 * Paul Tagliamonte:
 
  On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote:
  Florian Weimer has correctly pointed out that Oracle has decided to change 
  the
  BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/
  56.html). This hasn't been reflected in release tarball (probably by
  mistake), but since the AGPLv3 is not very friendly to downstream 
  projects, we
  (as the Debian project) need to take a decision.
 
  What? Wait, What? What?[1]
 
  The AGPL is a DFSG free FSF approved and OSI approved free software
  license? We made a decision, it's *free software* and fit for main.

For the record, I personally disagree with the FTP masters' decision to
accept works licensed under the terms of the GNU AfferoGPL v3 into
main:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721#28
But that's my own opinion, of course.

 
 The problems start when random, network-enabled, but non-web stuff
 switches over to the AGPL *without* implementing the Quine required by
 the license (which is somewhat difficult to do for a library, but at
 least there could be a give me a tarball interface).  That makes it
 difficult to perform local changes and stay in compliance with the
 license because you have to build the source code distribution
 mechanism from scratch and design a process that ensures the sources
 and running binaries match at all times.

This is indeed one of the issues of the GNU AfferoGPL v3.
There are other issues, as well.
My own analysis is here:
https://lists.debian.org/debian-legal/2007/11/msg00233.html

If those issues don't make people consider AfferoGPLv3-licensed works
as non-free, I think this license should at least be considered as
problematic.

Especially when a fairly widely used *library* switches from a
*permissive non-copyleft* license to a *highly restrictive* one (such
as the GNU AfferoGPL v3), I think the change should *not* be neglected
or taken lightly...


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpGpH87sNz4m.pgp
Description: PGP signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Jean-Christophe Dubacq

Le 02/07/2013 16:35, Ondřej Surý a écrit :
 Thanks Dan for this comprehensive email.
 
 I'll take ITP bug for libmdb (#694757) under pkg-db umbrella, as it will
 affect Berkeley DB, so it makes sense to have it there.
 
 People are most welcome to join the team, as I am the only active person
 in the team.
 
 O.

I happen to already have a private version of liblmdb packaged. As far
as I know, I met the following problems:

 * The library has no SONAME
 * I used a git (unreleased) version ; no tarballs of the source code
were made
 * the executables were statically linked.

I would be happy to continue the work on this library, albeit as a
sponsoree or something (I am not a DD nor a DM).

The git tree was not made public, but I can provide all of my work.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Howard Chu


Dan Shearer wrote:

On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondrej Sury wrote:


Florian Weimer has correctly pointed out that Oracle has decided to change
the BDB 6.0 license to AGPLv3 (
https://oss.oracle.com/pipermail/bdb/2013-June/56.html).

:

we (as the Debian project) need to take a decision.

:

(because the AGPLv3 is incompatible with GPLv2-only, and other licenses,
and there is code under these licenses which depends on BDB. There is
also code which depends on BDB that is compatible with the AGPLv3
legally, but whose deployment would then be restricted in ways the users
would not be expecting.)


As far as I am aware the most prominent users of Berkeley DB are
moving away from the library anyway ...


There are actually very few true alternatives to BDB. While there are
many KVP (key value pair) stores [1] not many are transactional, allow
multi-version concurrency control [2] and support multi-threaded and
multi-process access. BDB is all of the above, and in addition the BDB
API has become very widely used over nearly 30 years. And of course the
BSD license allowed BDB to be embedded in a huge amount of software -
like the BSD networking stack, it turns up just about everywhere.

So there are three things to think about in a replacement:

1. Is the licensing as suitable as the BSD license has been, and is
the primary maintainer likely to do what Oracle just did to BDB?

2. Are the features at least as good as BDB, and is the API close enough
to make replacement reasonably easy?

3. BDB is very old code. When replacing it can we also adopt modern
approaches more suited to modern hardware and use cases?

I've looked at all of the KVP options I am aware of and consulted people
who specialise in the space and can only see one that fits each of these
well. MDB from the OpenLDAP project, http://symas.com/mdb/ .

As to point 1, the rights holders of MDB need to make a public
statement, but I have asked them in private and in any case the OpenLDAP
history speaks for itself.


Just to be very clear about this, from the perspectives of both me
personally and the OpenLDAP Project.

Personally, I am a very strong supporter of GPL/copyleft. Having been a
gcc maintainer in the gcc 1.x-2.x days, and contributing to gmake,
screen, texinfo, and a variety of other FSF projects, it's been in my
blood for nearly 30 years. (Indeed, I have one of the oldest
GPL-licensed projects around, with a source revision history spanning
back 25+ years http://sourceforge.net/projects/arc/)

Another personal view I hold strongly is that a project's license
shouldn't change unless it isn't working for the users, or the users
approve of a change to cater for some anticipated need.

The OpenLDAP Project's license is BSD-flavored and was established
before I joined. As Chief Architect of the Project I see no reason to
change this. It has served the Project well with no user complaints. The
LMDB code was written for and is part of OpenLDAP, and we consciously chose to 
have it covered by the OpenLDAP license. Dan asks, in effect, will the LMDB 
maintainers do with the OpenLDAP license what Oracle just did with the BDB 
license?


The first thing is, nobody has privileged ownership of OpenLDAP code
because the Project does not require copyright assignment. It is not
possible for anyone to build a business model selling secret code
versions while preventing anyone else from building the same business
model through a license such as the AGPL.

Secondly, the OpenLDAP Project is not interested in any kind of
relicensing for any portion of our code, even given that it would not
put anyone in a privileged position. We can't predict the future, but we
have not seen anything indicating it might be needed. We know that there
are other projects which rely on OpenLDAP code being BSD-ish and we
respect that dependency.

There is another party involved who have funded a lot of OpenLDAP over
the years, Symas Corporation. I'm CTO of Symas, and I can tell you I am
quite pleased that even though the company is a good OSS citizen, there
is nothing that could happen in the company which would put Symas in the
position of power that Oracle has over BDB. So Symas' involvement is not
relevant to calculating the risk of a relicensing happening.

In short: OpenLDAP has no intention of relicensing and would not without
consultation with the community, and we have no intention of requiring
copyright assignment to us or anyone else.


As to point 2, MDB provides a superset of the KVP-specific features of
BDB, and the API is similar to BDB but somewhat simpler.


We deliberately modeled the LMDB API after BDB's transactional API because it 
made it easier for us to build an OpenLDAP slapd backend based on our existing 
BDB backend code. Feedback from other projects shows that our approach has 
helped others migrate easily as well.



As to point 3, MDB is a from-scratch implementation in the modern world.
MDB object code is a tiny fraction of

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Richard Fontana

On Tue, Jul 02, 2013 at 06:20:48PM +0200, Ondřej Surý wrote:
 I don't believe I have spread any FUD.
 
[...]
 2. AGPLv3 is incompatible with Apache 2.0 license (http://www.apache.org/
 licenses/GPL-compatibility.html)

Only in the same sense that GPL or LGPL (any version) is incompatible
with any noncopyleft license in the copyleft-to-permissive
direction. The Apache License 2.0 is compatible with AGPLv3 in the
other direction.

- RF


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702170356.ga16...@redhat.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Bernhard R. Link

* Paul Tagliamonte paul...@debian.org [130702 15:15]:
 Again, why do you plan on removing free software from main due to a
 change in license?

Licenses matter. Just because something it acceptable for Debian
main does not mean it is a good idea to have something licensed under
a specific license. So removing stuff if their license changes can
make sense in many situations.

And doubly so for AGPL. (I'll never understand why people consider it
free software, I'd not even allow the term freeware for it).

Bernhard R. Link



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702175730.ga3...@client.brlink.eu

Re: Berkeley DB 6.0 license change to AGPLv3

* Julien Cristau:

 On Tue, Jul  2, 2013 at 18:58:34 +0200, Nick Andrik wrote:

 Since AGPLv3 is really similar to GPLv3 but mostly oriented for
 webapplications, would it make sense to contact Oracle with the
 concerns raised in this thread and ask for clarification and possible
 consideration to change to license to GPLv3 instead?

 GPLv3 would be just as bad.  Changing a library from BSD to GPL is
 something you just don't do.

Previous versions of Berkeley DB have been released under the
Sleepycat license, which is actually a copyleft license.  It doesn't
conflict with further restrictions (which weakens it somewhat), but it
requires that freely redistributable source code is given to *all*
recipients of the binaries, which is in a way stronger than the GPLv3
(although copyleft extends in different directions, so it's hard to
two licenses as if there was just a single scale).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4fg3fhy@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

* Howard Chu:

 We can provide plenty more documentation on LMDB performance and
 reliability if desired.

Can you cope with incompletely written pages (e.g., only the first 512
bytes of a page is written) or write reordering between fsyncs?

Berkeley DB doesn't deal with torn writes, either, but it can deal
with write reordering.  The latter is what makes the checkpoints so
expensive, but I don't think there's a way around that.  You can
spread out the writes (PostgreSQL tries to do that, but it is not
entirely successful because of kernel API limitations), but then you
risk doing additional writes which are not strictly required for
durability.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwq43es5@mid.deneb.enyo.de

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Howard Chu


Florian Weimer wrote:

* Howard Chu:


We can provide plenty more documentation on LMDB performance and
reliability if desired.


Can you cope with incompletely written pages (e.g., only the first 512
bytes of a page is written) or write reordering between fsyncs?

Berkeley DB doesn't deal with torn writes, either, but it can deal
with write reordering.  The latter is what makes the checkpoints so
expensive, but I don't think there's a way around that.  You can
spread out the writes (PostgreSQL tries to do that, but it is not
entirely successful because of kernel API limitations), but then you
risk doing additional writes which are not strictly required for
durability.


We require that fsync() (actually fdatasync()) doesn't lie. Data pages can be 
written in any order, as long as all outstanding data pages are actually 
written by the time fsync returns. Given this constraint, you can pull the 
power on a drive and the DB will still be fine.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d3377a.7020...@symas.com

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-02 Thread Julien Cristau

On Tue, Jul  2, 2013 at 21:53:45 +0200, Florian Weimer wrote:

 Previous versions of Berkeley DB have been released under the
 Sleepycat license, which is actually a copyleft license.

Right, my bad.  I forgot about that oddity.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Berkeley DB 6.0 license change to AGPLv3