Darcs on this system (Ubuntu) links against the openssl library via
libcurl, and it looks from configure.ac as though it can be linked
explicitly when configured for git.  The openssl licence is
incompatible with the GPL, so the binary isn't legally distributable.

While you can link with a libcurl built using gnutls rather than
openssl, it would be best to add an exception to the licence to allow
linking with openssl.  You could follow the exception used for GNU
wget:

  In addition, as a special exception, the Free Software Foundation
  gives permission to link the code of its release of Wget with the
  OpenSSL project's "OpenSSL" library (or with modified versions of it
  that use the same license as the "OpenSSL" library), and distribute
  the linked executables.  You must obey the GNU General Public License
  in all respects for all of the code used other than "OpenSSL".  If you
  modify this file, you may extend this exception to your version of the
  file, but you are not obligated to do so.  If you do not wish to do
  so, delete this exception statement from your version.

I've requested and received permission to use a special exception like this from
most darcs authors.  I haven't yet checked for which significant darcs authors
haven't yet given me this permission.  Here is the ....  Oh shoot the list of
darcs authors who have given me permission is incomplete because some of them
are written on a hard drive that is in transit via UPS right now.

I'll get back to this issue next week.

fixing assignment.

I still haven't set up my workstation and thus gained access to my e-mail
archive that contains all the licence grants so far.  I'll (probably) get back
to this issue next week...

Yay, my workstation is back on line and I will resume work on this.  My next
step is to compare the list of people who've given me licence exceptions with
the list of authors.

Thanks for taking care of this!  Could you follow up on it, please?

Okay!  So my current status is that my workstation died again, so now I once
again don't have access to the list of contributors who had e-mailed me
permission to relicense.

I don't know exactly when I'll have a weekend to repair my workstation, so
perhaps in the meantime I should just ask everyone for permission again.

Could someone who knows more than me please generate a list of authors (with
e-mail addresses) who have contributed a sufficiently substantial amount to
darcs that their permission is required to add this licensing clause?

Thanks!

Right now you can generate a list of authors by patch count in the darcs source
(./list_authors stats).

Patch count might not be a good measure of significance (maybe somebody
submitted the one Patch That Changed Our Lives).  Maybe a more useful estimate
would be be based on the size of the patch (which is still bad, but the only
thing I can think of that we could automate...)

Zooko,

Any more progress on this? I'm upgrading this to "urgent" because of the legal
nature of the issue. You can add my name to the list of contributors who approve
the exception. 

The AUTHORS file lists about 120 contributors at this point...

On Jan 26, 2008, at 10:56 PM, Mark Stosberg wrote:

> Any more progress on this? I'm upgrading this to "urgent" because  
> of the legal
> nature of the issue. You can add my name to the list of  
> contributors who approve
> the exception.

I haven't done anything on it since my last update to the ticket.

At this point there's nothing that makes me more likely to succeed at  
this task than anyone else.  However, I've earlier offered to do it,  
and I will do it, but I request that someone else do the job of  
"deciding which authors have contributed a significant enough  
contribution that their approval is required to amend the licence".   
This is a fuzzy, legal, human judgment, not a precise mathematical  
judgment.  I am ill-equipped to do this step, as I know practically  
nothing about the history of the darcs source code.

> The AUTHORS file lists about 120 contributors at this point...

I guess this is an upper bound on the number of people whose approval  
we require!

Regards,

Zooko

I don't agree that this is so very urgent.  As far as I can tell, it only
affects distributors of darcs binaries who link with builds of libcurl that link
with openssl on systems where openssl is not part of the operating system. 
Which I guess means that perhaps it only affects Windows.  Even then, it's quite
possible to simply avoid the use of openssl.

I did recently add a configure option to link directly with openssl (for its
SHA1 code), but tests suggest that this has no performance benefit over the
gnulib code and it's not a big deal.  We could more easily remove that configure
option than relicense darcs.

David

Thanks for the response, David.

Since we don't ship OpenSSL with the code base, perhaps having a configure
option is not a problem for us either--- that's a decision the user or packager
is making. 

Perhaps this is "Not our bug" then, but something for packagers to work out? 

I had the sense that this issue might be preventing us from being legitimately
included in some Linux distributions, but it seems I am wrong about that. 

I'm not excited about the administrative effort for a licensing exception, either.

I would still be happy to do the work of writing to folks and asking  
them for permission, if only someone else will tell me to whom I  
should write.

Regards,

Zooko

> I had the sense that this issue might be preventing us from being  
> legitimately
> included in some Linux distributions, but it seems I am wrong about  
> that.

I believe there are differences of opinions on this (as on many  
licensing issues which have not been tried in court).

Another advantage of adding a licence exception would be to encourage  
people to combine darcs with Eclipse and redistribute the resulting  
combined work.

Regards,

Zooko

On Mon, Jan 28, 2008 at 03:34:38PM -0000, Mark Stosberg wrote:
> Since we don't ship OpenSSL with the code base, perhaps having a
> configure option is not a problem for us either--- that's a decision the
> user or packager is making.
> 
> Perhaps this is "Not our bug" then, but something for packagers to work
> out?

Right, at least in a sense.  We might consider it our bug, if this means
that packagers can't legally package convenient and useful darcs packages.
The only platform where this might seem likely would be windows.  Of
course, it also means that statically-linked linux binaries can't use
openssl, and there are people who provide statically-linked linux binaries,
it's just that they're much less needed on linux than under windows, and
it's not the end of the world for the statically-linked linux binaries to
not allow access over https.

> I had the sense that this issue might be preventing us from being
> legitimately included in some Linux distributions, but it seems I am
> wrong about that.

It depends on the distribution and how they package darcs.  Debian, for
instance, has two libcurl packages, one linked with openssl, and one
without.  Thus darcs can be built and used without openssl, and it's
unambiguously not a derived product of openssl.  But through the magic of
dynamic linking, the openssl-based libcurl can be swapped in by the user
all very legally (I believe... IANAL).

I believe most linux distributions are in the same (safe) boat.  Gentoo,
and other source-based distributions, have no problem at all.

> I'm not excited about the administrative effort for a licensing
> exception, either.

Indeed.
-- 
David Roundy
Department of Physics
Oregon State University

> I would still be happy to do the work of writing to folks and asking  
> them for permission, if only someone else will tell me to whom I  
> should write.

Could we narrow down the list to people have just contributed code that would
possibly use SSL? I believe that's the 'push', 'pull', 'get' and 'put' commands.

For example, I usually contribute docs and tests. Although I'm a contributor, I
don't feel I even need to be involved in this decision. 

Also, I sort of assumed I was giving over copyright ownership to the project
when I commit code, rather than gaining copyright on a small piece of the project.

On Mon, Jan 28, 2008 at 04:06:20PM -0000, Mark Stosberg wrote:
> Could we narrow down the list to people have just contributed code that would
> possibly use SSL? I believe that's the 'push', 'pull', 'get' and 'put' commands.

Alas, no.  Any code that is placed in compiled darcs would need to be
relicensed, since it's unambigous (to me, anyhow) that darcs itself is a
single work.

> Also, I sort of assumed I was giving over copyright ownership to the
> project when I commit code, rather than gaining copyright on a small
> piece of the project.

The problem is that "the project" is not very well-defined.  And in a very
real sense, the only constitution the project has is the license chosen for
the code.  And since that license has no provision for changing itself
(other than switching to a later GPL), we have to do this by consensus.

Note that we certainly could relicense files one at a time.  And then we
could rewrite files that have code from folks who don't agree with the
change (or inspect them to determine that none of those contributions are
still there).  But I don't think this is the best use of Zooko's time.
-- 
David Roundy
Department of Physics
Oregon State University

On Jan 28, 2008, at 9:06 AM, Mark Stosberg wrote:

> Also, I sort of assumed I was giving over copyright ownership to  
> the project
> when I commit code, rather than gaining copyright on a small piece  
> of the project.

Furthermore, I doubt that there are any darcs contributors who  
intended to prevent David from allowing darcs to be linked with  
OpenSSL or Eclipse.

So perhaps a fair way to proceed is to announce on the -devel list  
that contributors are henceforth understood to be giving their  
copyright to David so that he can do things like this, and that if  
anyone objects to linking darcs with OpenSSL or Eclipse, they should  
speak up.

Regards,

Zooko

> Note that we certainly could relicense files one at a time.  And  
> then we
> could rewrite files that have code from folks who don't agree with the
> change (or inspect them to determine that none of those  
> contributions are
> still there).  But I don't think this is the best use of Zooko's time.

I would guess that there aren't any contributors who object to  
allowing darcs to be combined with OpenSSL and Eclipse.

I don't mind spending my time writing to folks requesting permission,  
because I value having a low "barrier to entry" -- licensing hassles  
or uncertainties can prevent people from starting on something that  
could have become a valuable work, even if those hassles or  
uncertainties could have been overcome by additional workarounds or  
simply by being more willing to brave the uncertainty.

Regards,

Zooko

Zooko: please note the new release/openssl-ok file in the darcs repository.

I encourage you to keep your notes there (and submit patches!) so that they are
not as easily lost ;-)

Zooko, if you still have that list of authors who have granted you permission, I
would like to combine it with mine.  

I still have 62 people who have not gotten back to us, and would like to reduce
that list further before we start evaluating their changes on a case-by-case basis.

Attachments

• exceptions-granted-2008-06-09T09:26

On Jun 9, 2008, at 1:19 AM, Eric Kow wrote:

> Zooko, if you still have that list of authors who have granted you  
> permission, I
> would like to combine it with mine.

I'm sorry, but it is on a hard drive which failed.  So, it may be  
actually destroyed, or more likely it is sitting there in suspended  
animation until some far off year when I pay someone to try to scrape  
the data out of that hard drive.  :-(

Regards,

Zooko

What are the possibilities for compiling against gnu-tls instead of openSSL to
just avoid the license problem?

On Wed, Jun 18, 2008 at 09:54:16PM -0000, Michael wrote:
> What are the possibilities for compiling against gnu-tls instead of openSSL to
> just avoid the license problem?

That's fine.  The license problem only exists for people who want to
use openssl.

David

I maintain Debian's Darcs package, from which the Ubuntu package is
derived (by Iain Lane).  In the Darcs 2.2.0 release (which I am
preparing now), this issue will be addressed by the change below.
This change WILL NOT apply to Debian 5.0, as it is well into freeze.
I expect this change will propagate to Ubuntu in the near future.

Once licensing of Darcs is quite definitely cleared up, I will
consider readding libcurl4-openssl-dev as an alternative build
dependency.

I apologize for my slow handling of this issue.  I only found this bug
report recently; before I read it I thought the only thing we could do
about it was get licensing exceptions from every contributor.

--- darcs-2.1.0/debian/control  2009-01-22 13:26:21.000000000 +1100
+++ darcs-2.2.0/debian/control  2009-01-22 14:29:08.000000000 +1100
@@ -8,7 +8,7 @@
 Build-Depends: debhelper (>= 7), cdbs, ghc6 (>= 6.8.2-7),
  libghc6-html-dev, libghc6-http-dev, libghc6-parsec-dev,
  libghc6-regex-compat-dev, libghc6-http-dev, libghc6-mtl-dev,
- libghc6-quickcheck-dev, libcurl4-openssl-dev | libcurl4-gnutls-dev,
+ libghc6-quickcheck-dev, libcurl4-gnutls-dev,
  libkrb5-dev, texlive, tex4ht
 Homepage: http://darcs.net/
 Vcs-Darcs: http://repos.mornfall.net/darcs/debian

I (sigh) guess we could still work on this, although the fact that you could
just not use openssl makes me tempted to wont-fix this.

A first action to take would be to get a list of new patch authors since the
last time our exceptions file was generated.

Note that our switching to Cabal makes a few more authors moot since they only
contributed makefile/configure changes

Possible workaround for this would be to switch to GnuTLS library. Which
is especially tempting with recent heartbleed hype.

I find this all pretty ridiculous and am not willing to spend a single 
hour working on it. BTW, -fcurl nowadays needs to be specified 
explicitly.