Tech News » How NOT to Push a New Open Source License, Part 2

To those who whine "I don't want Google/Microsoft/Apple/whoever to use my code!" -- why not? Really, if you think they're evil because they close off code, how are you any better by doing the same to them? (plus, whining is for kids). "But it conflicts with our anti-copyright anti-business agenda." Put down the bong, grab a bar of soap, and stop acting like a freetard. You're giving the rest of us a bad name.

How NOT to Push a New Open Source License, Part 1

Maybe it's time for yet another open source license -- but Bruce Perens' covenant isn't it. Instead, consider this:

The Respect The Programmer License (RPL) Version 0.3

This file copyright (c) [year] [your name] [your email address]

All rights reserved.

1. You may use, create verbatim copies, and/or distribute this file, but you are not required to. You shall not modify this file or any copies.

2. If the file is written in a scripting language that runs in an interpreter, you may use this file, unmodified, in your program, and distribute it with your program.

3. If the file is a source code file that is normally used to generate a compiled program, you may use this file, unmodified, as part of the source for your program. You may distribute the compiled program with or without this file.

4. This file is provided "as is" and without any express or implied warranties, including, without limitation, the implied warranties of merchantability and fitness for a particular purpose.

5. The RPL is copyright (c) 2011 Barbara Hudson. Permission is granted to use the unmodified RPL to license your software. The canonical copy of this license, the release notes, FAQ, etc., can be consulted at http://milsecure.org.

End of license

For further information, contact Barbara Hudson at barbara.hudson@milsecure.org.

Interpretation/Deployment Notes

A. The RPL addresses one problem prevalent in most licenses, including the BSD, MIT, and GPL -- it's easier to just edit the file in front of you to fix a bug or add a feature than it is to contact the author and make sure everyone benefits. The RPL should eventually result in less duplication of effort and more, not less, sharing.

B. In the case of namespace conflicts (such as java or c++), please check to see if a similar file with namespaces is available from the author. The author will probably be happy to provide one, since you may not be the only person asking.

C. In the case of line ending conflicts, please check the author's website to see if there are Apple/Mac, DOS/Windows, or Linux/*NIX versions available. The author will probably be happy to provide one, since you may not be the only person asking.

D. If you need a modified version of the file, please ask the author. She or he may already be working on a new version with the changes you want. Alternatively, the author may be willing to write a custom version for you. Licensing terms for any such custom version are entirely at the author's discretion, and are not governed by this license.

E. This is an open source license -- you are free to view the code in this file and use it, intact, in any program you wish. This is not a copyleft license -- you are not required to distribute this source file with your program. This license grants you the freedom NOT to redistribute the source if you so choose.

F. You may charge any price you wish to distribute this file, and/or any program you create using it.

Remarks on the RPL

If code is written properly, it should be easy enough to integrate source files without changes. Worst-case scenario, those who use code licensed like this may have to create a "wedge" or "shim" file to interface between their code and the licensed code -- but that's good practice because it means that when an update is issued, the shim should mean that the new source won't have to be modified.

Not being copyleft means that it's more likely your code gets used. Some people will distribute it (in the case of run-time scripts, they really don't have a choice, right? :-) and this way you get credit for your work -- maybe not from the general public, but at least from your peers, which is what counts. People also know whom to contact for fixes and enhancements, leading to less waste and duplication of effort.

To those who whine "I don't want Google/Microsoft/Apple/whoever to use my code!" -- why not? Really, if you think they're evil because they close off code, how are you any better by doing the same to them? (plus, whining is for kids).

"But it conflicts with our anti-copyright anti-business agenda." Put down the bong, grab a bar of soap, and stop acting like a freetard. You're giving the rest of us a bad name.

Not being able to modify the source -- I can hear some of you going OMG THAT IS AWFUL! Hey, this is about respecting the programmer's copyrights, same as you can't modify that last book you bought. Since you can't modify or fork the file, maybe you'll collaborate with the author for a change, hmmm? Make sure bug fixes and enhancements get upstream. Or maybe even *gasp* pay them for some custom code -- or send a gift certificate for chocolate or a bottle of booze or something.

This isn't inspired by Borland's "Just Like a Book" license for its compilers (you could order the source libraries to examine, but not modify or share), but it has similarities. It's an improvement in that you can distribute the source if you want, and you can have multiple copies. But like Borland's license, you are not free to modify the code itself. Most projects should be able to accommodate that sort of limitation.