Wim Godden <[EMAIL PROTECTED]> writes: > I couldn't agree with you more. As one of the main developers of phpAdsNew, the > number one banner rotation system for php, I know it's hard to keep things free, > but at the same time I believe that, once you commit yourself to producing GPL, > you can't withdraw your effort and code.
Although you cannot withdraw code licensed to the GPL, it is possible to add new code and state that it is non-GPL. You can still distribute the package, but there's no requirement to distribute the non-GPL'd code. Effectively you are forking the project and dual licensing the software, which is entirely permissible. Two examples of this are GFS and SSH version 1. > FreeVSD has a bright future, if its documentation improves to a more technical > level as well. What we really need is a manual which explains how FreeVSD was > built, what its structure is, etc. If someone can write such manual, I'd be very > willing to help out in the project. But the way it is now, it'll cost me too much > time to get to know how FreeVSD works. > > The key to GPL is cooperation. Look at the Linux kernel... lots of people > contribute and everyone gains from it. But here too, there's hardly any > documentation on how to start kernel programming (there are a few docs, but > they're awful). > > It's fine if you write good code, but without documentation, you'll be the only > one writing the code. Because of that, it may seem as if others are making money > from the effort you put in. But if you write documentation, others will be more > than willing to join in. I disagree with you here. I have contributed to a wide variety of GPL'd code over the years. My contributions were inspired by features that I wanted to see in the program and after looking at the code, I figured I could implement them. What you are asking for is a design document of the original authors mind, including the direction in which he wants to take the project and why the code is structured the way it is. This, I think, is a fruitless exercise, since any hacker can make their changes and submit them to the original author. The author can give the hacker feedback on their patches, possibly asking for resubmission with style changes and corrections required to meet the coding standard and design that the author has decided upon. Eventually, after the hacker as written patches for a wide area of the application, he will soon understand the design decisions that the author has been making. The ultimate goal is to get CVS write access to the source tree, which only comes by proving your worth. This procedure is implemented on nearly all projects by their maintainers since their is no guarantee that the hacker has read the documentation (and in most cases, they won't). People will contribute to a project if they like the software but would like to see a enhancement to fulfill their needs. Some will make the time and take the effort to do this, while others may simply put requests onto the mailing lists. Regards, Nick. ------------------------- The freeVSD Support List -------------------------- Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support Archives: http://freevsd.org/support/mail-archives/freevsd-support -----------------------------------------------------------------------------
