Oliver White wrote:
>
> "Ronald L. Chichester" wrote:
>
> > Several lawyers have addressed the issue of GPL "infection." The rule
> > of thumb is: if you mix GPL source code with other code to make new
> > binary executable, then that other source code is subject to the GPL.
>
> It's even less restrictive than that. You can link GPL code to, say, the MFCs. What
>you can't do is proprietary
> code to the GPL. Now... I'm not entirely clear on this distinction myself, but
>there's a certain directionality
> to the licence. How this all relates to interpreted Python code, I really don't know.
Python has its own license. Incidentally, RMS has had some trouble with
the Python license. None of my clients, however, have felt the need to
address the Python license (unlike the GPL).
If you want to have a discussion on this, just remember this. When you
strip things to the chassis, the key difference between the GPL and the
BSD license is that the GPL requires a grant-back for modifications.
The BSD doesn't. In our case, a BSD "protected" FreePM would be
suseptable to being taken in by a major conglomerate, modified to
include proprietary formats, and then sold to a number of physicians.
Same functionality, but different file/protocol formats would render it
unlike the rest of FreePM. The project then, would be effectively
forked. The GPL would prevent this.
The question then, is do you consider the potential for forking to be
great or small? If you want to preclude forking as much as possible,
then look to the GPL. If forking is not a concern, then the BSD license
will be okay.
The Apple experience with Darwin and OS X (based on FreeBSD, with the
BSD license) is a perfect example of a BSD style license being used by a
company to take a code base and make it there own. That couldn't happen
with the GPL (assuming Apple played by the rules).
Ron
./.
_______________________________________________
Freepm-discuss mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freepm-discuss
