Licence Specified Inclusion Requisites...

[David Johnson]

On Saturday 22 June 2002 12:21 pm, David Johnson wrote:

> I've got concerns about conditions three, four and five. I have to think
> about them some for time. I'll attempt to comment on them later after I
> have digested them.

Okay, I've thought them over a bit. In a nutshell, your concerns are valid but 
I don't think they belong in a license. Not everything you wish people to do 
should be in a license. If you're not willing to sue someone over a license 
term, don't put it in the license.

I fail to see the need for standards documents in a software license 
(condition three). I'm assuming that these include coding standards, 
documentation formats, etc. I have strange visions of <Copyright Holder> 
suing a contributor for using XHTML/CSS instead of DocBookXML, or for 
indenting code three spaces instead of the specified four. Standards 
documents are for the benefit of the project, not a mandate on potential 
contributors.

So do what every other Open Source project in the world does: request (outside 
of the license) that the standards be followed, and if submissions don't meet 
them, either reject them or reformat them. But don't place legal restrictions 
upon the formatting of any derivative works. If this is a really big deal 
with you, then you might wish to merely require a name change when the 
standards are not followed.

Condition four addresses a different kind of documentation, that seems to be 
refering to software specifications. First, it is very vague. Does it include 
comments from code reviews? Call trees? Profiling analysis? Does it extend to 
third party libraries? More importantly, will you sue a contributor who 
failed to properly document a bug fix?

I have to document this kind of stuff at work. It's a very onerous task, but I 
do it because they pay me to do it. I document *some* of this stuff for my 
own personal projects. It's still onerous. Which is why I don't do it on a 
continual basis. But condition four will require potential contributors to do 
this before every release and without pay. That will put a big damper on 
project enthusiasm.

My suggestion is to dump the license and use the standard BSD, MIT or a 
derivative Apache license, and make all of the documentation and standards 
requirements into polite requests. Put the standards up on the project 
website. Don't accept contributions without documentation.

p.s. The Apache Project is a good model to follow. They have excellent 
documentation of the kind you mention. They are the paragon of software 
engineering in the Open Source world. Yet they need no terms in their 
licenses requiring standards or specifications.

-- 
David Johnson
___________________
http://www.usermode.org
pgp public key on website
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3