Open Sourcing Windows Based Project

metasynth asks: "The company I work for has developed a timer system in Delphi for Windows machines. I'm currently trying to convince my boss to open source it as the program is to be used to help develop a community around it. I'm looking for good arguments to open source the system, and details (or links to details) of how to go about it. What type of license should we use to allow us to keep reasonable control over the project, e.g. a license where anyone can download and work on the code and distribute it as much as they want, but have them send us back the modifications that they have done for us to decide whether or not to include them in the offical release. One other question is: What sort of interest is there in the Slashdot comunity for a windows based open source project?"

Netscape Public License

These are the exact terms used in the Netscape
licenses.

Just make sure you continue to lead the
development. Learn from the early lessons that
the Mozilla project teaches us - don't expect a
public license to mean that a ton of developers
will magically develop things - there needs to be
a leader who does a majority of the code (exactly
how Linux was in the early days).

Mark

License Suggestions

I think the artistic license has some provisions for "keeping control" of your project. However, the artistic license has some holes in it that were explained to me once but I now forget them. I won't start a license flame war, but I will suggest the GPL.

The fact of the matter is, however, that if you are the primary contributor to the project, and/or are in the position of the "maintainer," you should have no problems with the project pretty much following your intended direction. If there is enough dissension among your contributors, there is always the possibility a fork will form, but nothing anybody can do can remove anything from your project.

As for making sure that modifications are propagated back to you: This isn't possible under the GPL (which is what you want to use), and isn't really enforceable even if a license did provide for it. However, if you are the maintainer/principal contributor, people will be pretty likely to try to get their code included in the release, and if you use the GPL they will have to use it, and so, for example, they couldn't (legally) distribute their own binary without source.

One more thing : you would have to be responsible (unless you copyright the code to the FSF) for prosecuting anybody who violated the license. I don't think it happens often, but it is something to keep in mind.

UCITA

The GPL is actually a license (i.e. granting you additional rights to the ones that you already have) as opposed to most other "licenses" which are really restrictions on rights you have. Most jurisdictions allow someone to grant you additional rights without requiring your permission, but you must explicitly agree (i.e. sign something) to give up rights. Therefore, "shrink wrap licenses" are not enforceable in most jurisdictions.

Here's where UCITA comes in. Everyone knows that it's evil because it will put teeth in those "shrink wrap licenses." To those of us who do not use shrink wrap software, this is no big deal. The flip side is that it would give razor-sharp piranha teeth to the GPL, and if you could actually prove that someone was distributing software in violation of the GPL (i.e. I take GNU Emacs, hack it a little bit, and sell it without releasing source code), then they can be not only sued, but also charged with a crime! Chances are if you can prove they did, they'll be convicted or found liable for damages.

If you think about it, UCITA is our friend. It could have the effect of driving people away from the ridiculous and uncertain "licenses" of shrink wrap, commercial software providers towards Open Source, GPL software.

So, that's my new mantra: "UCITA is your friend."

Delphi Open Source Initiative

Here's a site for Open Source Delphi projects:

http://delphree.clexpert.com/pages/default.htm [clexpert.com]

Re:Could be great

While I agree that OpenSource will hit Windows next, there is a LARGE obsticle there, and it's surprisingly not due to Microsoft.

With almost all unix systems, you have "cc" or some varient, and "make" and some varient. Additionally tools, such as automake, etc, help with system dependances, but in general, all you need to do to build an OS program is untar, ./configure, and make all.

On the Windows side, however, there is no preferred developer enviroment. Yes, you can get Cygwin tools with come with gcc and make and all other unix tools, but I would suspect that less than 1% of Windows programmers know about these. Most are used to visual environments where the concept of a makefile is not well know. Thus, if I was to do an OS Windows project, I'd need to supply a project file for all the major IDEs (a task in and of itself). Then I have to worry about all the slight differences in how the compilers work; something may compile out of the box fine on Borland C++, but fails miserably under Microsoft Visual C++. The solution in most of these cases is not quite as simple as having #ifdef _UNIX_ in the source; there are probably major revamps to the code to make sure it works. And I haven't even mentioned propriatary extentions to the languages yet by each vendor.

With that said, if you do approach an OS project, make sure that you stick to ANSI and Win32 APIs calls as close as possible, and avoid using compiler features. Try to follow how UNIX code is set up; maybe, just maybe, someone might want to port your app from Win32 to Unix, so keep GUI and engine functionality separate. Try to know the various differences between the IDEs avaiable. I believe you can also compile Win32 code using the Cygwin gcc compilers, so this might be a good test of how portable your final code is for open source distribution.

PRF license

Where I study (a research center at Purdue University) most of the research projects for which code is developed are made publicly available at some point. However, as most of them are considered "research prototypes" and not full production systems, they are initially released under a restrictive license (written, at least in my case, by the Purdue Research Foundation), that provides for people to give us back any modifications they make, as well as feedback about their experiences with the system.

I don't think there is any way of enforcing these terms (on people giving back changes and feedback), but at least it's there in the license. Since we do not profit from these projects (at least not initially), we are interested in the feedback mostly for academic purposes anyway, so enforcement in our case is not much of a concern.

You can read the license for the AAFID [purdue.edu] project (my main project now) here [purdue.edu].

--Diego

Tcl Extension Architecture (TEA)

At the Tcl/Tk Conference, Brent Welch of Scriptics presented a paper on TEA. From the abstract:

"The goal of TEA is to create a standard for Tcl extensions that makes it easier to build, install, and share Tcl extensions. In its current form, TEA specifies a standard compilation environment for Tcl and its extensions. The standard uses autoconf, configure and make on UNIX and Windows."

Specifically, the standard uses Cygwin on Windows. More info is available at: http://dev.scriptics.com/doc/tea/

One huge advantage to using TEA is that you won't need to recompile your extensions for each new version of Tcl/Tk (as long as you only call the public APIs).

Re:UCITA

The GPL grants you some rights but also restricts some rights as well. Nothing in life is free... Maybe free as in beer, maybe free as in speech, but there's a 3rd aspect of freedom which I can't name, but what must exist. Specifially, the GPL refuses to let you take your changes private. That's a restriction, if i'd ever seen one. Yes, the GPL is good, but in terms of projects that may become commercially viable, a LOT of thought needs to be put into using the GPL...

For instance, co-opting. If Sun had licensed Java to Microsoft under the GPL, we'd have a completely fragmented Java right now. Microsoft could have made whatever changes they wanted, given the code back to sun, who would reject it, but then continue to distribute their code to the masses. Sun used a much stricter license, which means they could sheppard Java, make sure it was going in the direction they had forseen, and try to beat back people from outright destroying it.

For all the advantages UCITA offers to open-source, it doubles that in disadvantages... Would Linux even exist if reverse engineering were barred? How about star office? UCITA strictly states that reverse engineering, even just for interoptibility, is barred. So, existing open source software would do just fine and dandy... But new projects intended to say, interoperate with MS Windows 2001, would be completely out of the picture, unless they were developed in whole outside of UCITA's grasp... Even then inviduals might be able to download those projects and use them in the States, but large companies certainly wouldn't want to take that chance.

Re:Naah, you're WAAAY wrong here.

"And what would be the benefit of his "hang[ing] it all out and go[ing] BSD" -- except that that would make it perfectly legal for some sleazeball "entrepreneur" to hijack his code base, close it off, and start selling a "competing" copy of his work?"

Oh please! I made it 80% of the way down the page without seeing any bullshit being slung about (which is amazing considering the topic), then I see you comment.

I'll tell you what the BSDL does: it allows Apple to use 4.4BSD code in MacOSX without having to give anything back, yet they still give back! When you treat your users with respect, you'll get respect in return. But when you treat your users as potential thieves, don't be surprised when your users choose other software.

My apologies to any GPL developers who treat their users with the respect due them. You are the vast majority. My tirade is only directed to the tiny minority of self-righteous license bigots.