[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [kDev] Bruce Perens replies - suggests modified BSD...
I sent a response to Daniel, but he asked me to send one to the list,
so I'll send essentially the same thing here.
It's also given me a chance to think things through a little more. I
know this is a critical area for many of us, and feelings as well as
business needs are deeply affected by it.
On Wed Jun 2 08:11:15 2004, Daniel Harris wrote:
Begin forwarded message:
From: Bruce Perens
This does not require that you join some GPL vs. BSD argument. The
BSD license without the advertising clause is GPL-compatible, and
is chosen for strategic reasons of your project.
I would caution you that proprietary forks of your product are
likely, and this may dissuade volunteer coders who will start to
see themselves as unpaid employees of the folks making the
proprietary fork. But the Apache project seems to be able to live
The above two paragraphs are, in my opinion, incompatible.
The Kendra project only remains worthwhile if all deployments are
fully interoperable. Proprietary forks will almost certainly drift -
this hasn't happened with the Apache project on the face of it, but
looking closer you'll note that while the forks of Apache remain true
to the HTTP/1.1 specifications (et al), different forks operate with
different plugins - it's impossible to run Websphere applications on
'stock' Apache, for instance.
This isn't a problem for Apache, in reality, but that's largely
a) Different forks loading each others special stuff isn't an issue,
b) Different forks all support the same module loading API, for
instance, so all Apache modules all work with everyone's fork. This
is because of inertia, largely, and the fact it's a proven API that
works. Writing a new one is both worthless and difficult.
c) Different forks all support the same protocols, because Apache is
essentially a pure server - it provides no end-user client, thus has
to speak the protocols both accurately and pragmatically.
Some of this applies to Kendra's output, but not all, and especially
not (c), which is crucial.
1. Protect developers and Kendra from being sued because what we
created or help create screws up someone's business - so we have
no implied warranty.
On the one hand, all open source licenses I've looked at include a
warranty limited as far as is possible within the law. On the other
hand, certainly under UK law, even gifts have an automatic warranty
to an extent.
I suspect that the distributor would have liability, and would have
to 'sue up the chain', as it were, for a developer to get sued
themselves, and I also suspect it'd be extremely difficult.
But it's a point to look into, if it worries you.
2. Protect from people coming along and saying "hey, you guys
stole my code" - so clarification of ownership.
The BSD license includes this, as do any open source licenses.
Moreover, copyright law itself stipulates this to a large degree.
(The GPL is actually rather more explicit.) Moral rights make the
issue even more complex.
3. Let people do anything they want with the code. No legal
restrictions what so ever.
This is not actually covered by any open source license, which may
The reason is that terms describing usage, with the exception of
curiosities such as public performance of the work, are outside the
scope of copyright law.
'Commercial' software licenses are, in fact, not a license as such,
but a contract. In general, they rarely contain a license (although
the 'redistributable binaries' bit of development suites constitutes
a copyright license), but contract law is a fearsome beast, and in
general requires an exchange of some kind to make the contract
binding, which doesn't happen with open source.
Hence OSS licenses are restricted to specifying copyright terms,
which don't cover usage at all.
[Re]distribution of the original work and derived works is the only
thing covered, and it's worth noting that what, exactly, constitutes
a derived work in software is pretty vague in places.
4. Not having to choose sides in the GPL/BSD battle. Is it just
me? After speaking to both "sides" I get the feeling that if I
were to choose either the GPL or BSD then I'd instantly be seen
to reject the other. Or is it that I've just been speaking to
The question you need to answer is twofold:
- What license[s] should you distribute the original code under?
- What license[s] are you prepared to accept for contributions?
Bruce made the suggestion that since the BSD is GPL-compatible that
this somehow side-steps these issues, but it doesn't. The BSD is
indeed GPL-compatible - meaning that you can redistribute BSD
licensed code under the GPL legally - but the GPL is not BSD
We - the people on this list - can certainly help you answer both
questions, but ultimately, you're the copyright holder, and you may
license your copyright under any scheme you like, and as many of them
as you like.
There's also the question for contributors:
- What license[s] are you prepared to license under?
This is a personal or company choice.
From a corporate perspective, I've always considered that the GPL
makes most sense for larger projects, since it prevents anyone else
from leap-frogging you - building on your work, but not allowing you
to benefit as well. The GPL works well for informal consortia, too,
since no member gains an advantage over the others.
From a personal perspective, the situation is very much less clear
- not that it's clear to begin with - but personal choice makes up a
larger proportion of the decision-making process. Some people simply
prefer BSD licensing.
Of course, Bruce's comments above the the BSD is GPL-compatible also
means that if you licensed Kendra's output entirely under the GPL,
you could accept contributions legally that were licensed under the
Conversely, one could take a BSD-licensed codebase, add a small
amount of GPL-licensed software, and the result is a work which can
only be distributed under the GPL - so it's worth noting that under a
BSD license, a proprietary fork is not the only possibility.
Public domain is a specific legal term, essentially indicating that
there is no copyright on a work. This contravenes 2 totally, and
certainly doesn't make 1 any better - it probably makes it worse in
some parts of the world.
If I have a license with a warranty disclaimer, a copyright
notice but no requirement for the license to be attached to
modified/redistributed works is this, in fact, public domain?
Anything wrong with that in terms of protection points 1 and 2?
Would licensing under a dual or triple license (GPL/BSD/?) help
Dual licensing is, I think, pointless.
The use of dual-licensing models is generally that you license under
GPL, or something similar, which essentially enforces open source,
and also under a proprietary license (or contract) for proprietary
uses. It's a demonstrably working method of generating a profit.
Dual licensing in this way for Kendra would simply mean that Kendra
could make a profit - given it's a non-profit, I'm not sure that's
Dual licensing between BSD and GPL is especially pointless.
The real problem is that you actually cannot dual-license as such.
All you can do is offer more than one way of distributing the code.
But for the act of distribution itself, there's only one license in
effect, and that cannot be changed retrospectively - if I download a
dual-licensed Kendra under the GPL, I cannot then redistribute it
under the BSD, as that contravenes the license I used.
The dual license you suggested is so pointless because in the case of
the BSD/GPL, I *can* download a copy under the BSD license, and apply
a GPL license to it anyway, since the BSD license says, in effect,
that I can redistribute under any terms I like. I might, at a pinch,
have to add in a token change to make it a derived work, but I don't
think I even need to do that.
But, all that aside, I do think multiple licenses may be the answer
here - just not in the same way.
The overall design of the Kendra software will have several distinct
blocks. Some of these blocks we can consider 'Core' - stuff like, I
dunno, catalogue aggregation, data exchange, etc. There's lots of
these areas. To me, this sort of code is probably best done under the
GPL, with various exceptions. It ensures that the core code of Kendra
remains a level playing field for all those concerned, and ensures a
high degree of commonality.
Additionally to this, there's be numerous APIs, plugin layers, and
all sorts of things bolted onto this. For an obvious example, there'd
be a storage interface.
Supposing Kendra licensed a reference database storage plugin under
the BSD license. It'd mean that binary-only storage interfaces could
legally be developed. Some people may well write GPL licensed plugins
based on the reference code as well - that's okay, too. Personal
But it keeps the core stuff - that which allows the plugins to all
work everywhere - common and open, prevents the proprietary forks
Bruce Perens mentioned, while still allowing closed-source
involvement and highly liberal licensing for the non-core stuff.
The scope for possible proprietary exploitation is huge - management
interfaces, reporting systems, all sorts of things. If they need the
available APIs extended to support them, they have to do it through
the GPL'd core - and that means two things:
1) The GPL'd core's APIs will get richer, for the benefit of all the
2) The APIs will generally have to remain backwards compatible, since
various different parties will be relying on them. In the case where
they *have* to change for some reason (Like bad design), then
there'll have to be a reasonable consensus for them to do so, and how.
As I said above, this will need a specific exception as an addendum
to the license terms - typically, this might be 'GPL, but linking
with otherwise GPL-incompatible software is allowed' - there's a
whole bunch of information on the FSF site about this.