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