[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 with this. 



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 because:
a) Different forks loading each others special stuff isn't an issue, it's expected.
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 surprise some.
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 hardliners? 



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 compatible.
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 BSD.
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.
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?
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.
Would licensing under a dual or triple license (GPL/BSD/?) help point 4? 



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 the idea. 

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 choice.
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 developers.
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. 

Dave.