cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: curl::easy 1.1.6 tarball

From: Cris Bailiff <c.bailiff_at_awayweb.com>
Date: Tue, 11 Sep 2001 18:02:04 +1000

Daniel Stenberg wrote:
>
> On Tue, 11 Sep 2001, Cris Bailiff wrote:
>
> > Georg stated his code was 'Public Domain' (legally, free of any licence)
> > and so I said my contributions were made to Daniel under the same terms
> > as the rest of curl (MIT-X/MPL), making it easy for Curl::easy to be
> > included in the main curl distro.
>
> I don't require them to be the same as the rest of curl, they can still be in
> the same distro (which in itself still is a separate debatable issue of
> course).
>
> > I or Daniel can edit the documentation for Curl::easy in CVS to make this
> > clearer.
>
> I'd appreciate if you could take care of this. I'll volunteer to put together
> a 1.1.7 package with it when you're done.

Fine - to make a separate package can be just a 'make dist' in the
Curl-easy directory...

> > If Curl::easy is going to live 'standalone', it might also make sense to
> > explicitly licence it under the usual perl Artistic/GPL dual licence as
> > well, if this is possible, otherwise it's just MIT-X/MPL.
>
> I think Curl::easy should be targeted at living "standalone". We're getting
> more and more language interfaces to libcurl and we can't include them all in
> the curl archives.

OK - but I think it should be 'in' or 'out', rather than copied - I
don't have acccess to the curleasy project at sourceforge, I think Georg
is the admin of that one, and I don't know if its currently up-to-date
or active...

> So we should make sure there's correct license information in the curl::easy
> archive.
>
> > Perhaps Domenico can tell me if these 4 are compatible :-)
>
> Those 4 aren't "compatible" among each other, but that's also why they're
> dual. The two dual versions are "compatible" with each other (and with plain
> GPL which probably is important to people).
>
> Still, there's no real point in using Artistic and I don't urge anyone to use
> the curl dual license. Future versions of curl/libcurl will go plain MIT.
>
> Now, Georg has explicitly asked his package to be put in the Public Domain,
> so I think we should not argue and go with it. In fact, it being public
> domain makes it possible for anyone at any time to put it under another
> license.

This is the issue though - public domain offers no rights or protections
to any of the developers. I didn't want to contribute to Curl-easy
(just) the GPL, because I want to use curl+perl in customer projects
(commercial) without pain.

Yes, I know I retain my own copyright and can re-use my code under other
licences, but I'd actually prefer to be able to assign my copyright
elsewhere (esp. to Daniel or some subsequent curl or Curl-easy
maintainer) without worrying that other people's contributions would
suddenly prevent me from using the mainline Curl-easy sometime in the
future.

Under public domain, some new developer or greedy company could just
announce the code is (just) GPL, or completely closed/commercial, and
either way, prevent me from using it freely, so I don't want to
contribute my code as 'public domain' either.

If everyone agrees, I'd rather state explicitly (in the Curl-easy
package) that the Curl-easy package is under the same licence as curl
and libcurl, the MIT-X/MPL licence.

As Georg is clear that his code is 'public domain', I can actually
declare this unilaterally - I could theoretically do whatever I like
with Curl-easy <= 1.1.2, including claim it as my own, and release the
entirity of Curl-easy-1.1.6 under any licence I choose. I choose the
curl licence.

I'd much rather do this by mutual concensus than unilateraly though...

God, I hate licencing....

In summary:

I will update the README and other docco in Curl-easy in CVS to read
that Curl-easy is licenced entirely under MIT-X/MPL, the same as curl.

I will do this tomorrow (12th September at 18:00 AEST) unless I hear a
well reasoned objection before that time.

Cheers,

Cris
Received on 2001-09-11