Hi Michael. I really like the idea of dual licensing. It was something I
had also suggested for SQLObject a while back but it was too late. There
are many fine resources that have opted for this approach. I have not
had very much exposure to the MPL in relation to python but it is
worrisome since like LGPL these is much language and as a result, many
more possible interpretations.
On the issue of a super sqlalchemy, I think here there is only one that
could possibly be super. This would be the one advanced and supported by
an active community of developers (not a one off horse that wants to
race on the backs of the core developer(s)). That said, removing any
barriers to use could easily make this the leading python ORM since the
python community is screaming for something really good to work with
that is as easy as working with the python language itself.
One thing that comes to mind about MPL is that the issue of what
constitutes a modification will continue to be debated and it is
difficult to anticipate all use cases for python. For example, does the
sql generated from from library become a modification? Does the need to
embed the library in a wxPython app and somehow link the files now
create an issue for the developer to contribute the code back. How
about assembling things together in an egg etc or importing parts of the
library in your code. I believe this is still fairly grey because of the
dynamic nature of python itself. I believe this is why python itself has
stayed with a very simple license and very simple language.
As far as I am concerned MPL and LGPL licenses have far too much
language - period. The more language that is contained in the license
itself, the more it can be interpreted and constued. The iterations of
any interpretation is only multiplied by the volume of legalese. Let's
face it, we are not lawyers, we are developers. It would be good if the
python principles could be applied to licensing as well. At least the
parts concerning simplicity and making things plain and understandable.
The fact is most of these licenses have almost no legal precedent in the
first place that makes this even more confounding.
For myself, the last place I want to be is in front of a client some
years down the road advising them that their project must be contributed
back on something they paid me for because of a recent court ruling. I
have made deliberate efforts not to draw my clients into any sort of
issues that could bite them in the ass some time down the road. I am
also their guide as well, more so for small clients.
One thing I am really hoping for is that someone will step up to the
plate without the fear of loss of the code to some corporate giant. I
don't feel this is realistic and unfounded. Django, Ruby and Turbogears
are all examples of excellent projects that have demonstrated their is
nothing to fear by making a deliberate effort to license liberally. Why?
Because it draws people together and has demonstrated it can provide a
long term sustainable base of support. Keep in mind this is a library
not a consumer product and your audience is developers. What developer
would pay 299 for a library that is open and supported best by its own
community? I feel this library has some very excellent potential and
feel that BSD, MIT or python license would give the project the best
traction and a real future.
What has really disappointed me over the past years has been to see the
initial propagation of some really good projects and ideas only to see
them left unsupported and die a slow death on sourceforge. As a result,
they are left out of main stream python programming and fade into
oblivion instead of seeing their full potential realized.
I mean look at the array of small projects out their in any particular
area, any of which do not get adequate attention and as a result never
get beyond a few of the core developers until they move on to something
that is more stimulating or abandoned because there just is not enough
momentum behind the project.
The ORM area is very much like this. Perhaps the biggest attention
getter here is SQLObject. You only need to look at the mailing list here
to see that licensing is a concern for use in commercial projects.
Unfortunately, statements of intent do not give me very much comfort and
the author of this project had also indicated that he would never choose
this sort of license if he could do things over again. I will not use
the library because of the licensing and will not put my clients at
risk. Further, it is just too far gone for this type of change to occur
realistically. This gets to be extremely difficult afterwards since you
must have the agreement of everyone that has contributed code.
The Django db api another example. lt is licensed in a way that is
creating positive change even as I write this. This project has
attracted a strong following of those that are interested in making it
excellent over time incrementally. As it stands, the release of 1.0 has
not arrived but there are now sweeping changes being made to the api and
Django's management interfaces as a result of the involvement and
feedback of a strong community to make it better. It is a demonstration
of good will and communtiy gettting behind something better for everyone
in the long term.
Turbogears is another good example with a philosophy of striving for the
best of the best and using existing projects. I was reading Kevin
Dangoor's blog before Christmas and it was inspiring to see what is
happening with this project. It is bringing together many of the ideas I
am speaking of. On top of it you are getting synergy from the
communities of developers from each project. For example, people from
cherrypy, or Mochi and others. As a result, you are seeing a real
demonstration of the perpetuation of an excellent combination of
projects with liberal licensing. Originally Django was ahead of
TurboGears for community. I am on both lists and the volume of people
involved with turbogears has well surpassed Django in the past months.
In anycase, I prefaced my mail by indicating inquring about license
change to SQLObject list. I wanted to use this in my sql projects a
while back since this is an effective ORM and I have experimented with
it and it is works very well (and this is something really needed for
python generally). For SQLObject it was too late to change, but for your
project it is not.
I believe this project has the potential to make a large impact for
python programming and really hope you consider not the MPL but BSD, MIT
or python license instead. My feeling is that you would not be
disappointed since it would draw many to this work to improve this ORM
and see it rise to its full potential without any shades of grey around
a verbose license license that inhibits its use.
Regards,
David
Michael Bayer wrote:
Glad you asked, I already have been looking into migrating to a dual
LGPL/MPL license, where you can select either one. I believe the MPL
should get around the ambiguity of the C-ish language still present in
the LGPL.
the MPL is at: http://www.mozilla.org/MPL/MPL-1.1.html
With regards to copyleft, the FAQ has this to say:
How 'viral' is the MPL? If I use MPLed code in my proprietary
application, will I have to give all the source code away?
The MPL has a limited amount of 'copyleft' - more copyleft than the
BSD family of licenses, which have no copyleft at all, but less than
the LGPL or the GPL. It is based around the definition of a
'Modification' in the license [1.9].
What is a Modification? Any changes to MPLed files, or new files
into which MPLed code has been copied, are Modifications and so fall
under the MPL. New files containing only your code are not
Modifications, and not covered by the MPL.
Files which fall under the MPL because they are or contain
Modifications must be made available as detailed in the license (or
elsewhere in this FAQ.) Other files may be kept proprietary.
One well-known example of this is the Netscape-branded browser. It
contains (and Netscape makes source code available for) many files from
the Mozilla project, which are under the MPL. But it also contains
proprietary code, for example to integrate with the AOL Instant
Messenger service.
i am hoping this license will meet the needs of the commercial
community (because yeah, that is a big target for this thing) while
still keeping SQLAlchemy free and open (because I dont want some
compelling "Super-SQLAlchemy" to sell for $299 a developer seat). Let
me know how that works for you.
On Dec 29, 2005, at 10:36 PM, David Pratt wrote:
I have read with interest about sqlalchemy project, however the
licensing for the project is a concern to me. Byte compiling makes
the lgpl licensing ambiguous when it comes to python. There is also
too much language concerning the issue of compiling in the lgpl that
confounds the use of sqlalchemy in the development of compiled
desktop applications.
If the intent is to create a broadly accessible and successful python
library and ORM, I am hoping the license for the project can be
reviewed and at the very least reconsidered. A BSD, MIT or python
license basically permits the library to be used in the widest sense
- as braod as python itself - while ensuring credit is given to the
copyright holder(s).
This looks like an interesting project and a library I would like to
have available in my python toolbox. I believe the best way of
getting sqlachemy used in projects is for the licensing to be
comparable to python's licensing itself so it is not an issue to
consider whether it will be used (as opposed to rejecting it for
business applications where companies are more sensitive about mixing
with anything gplish).
I am not interested in a holy war over licensing since there can be
fairly strong view on either side. I am interested in useful ORM that
I can use on a routine basis to wrap sql in an nice way for python
without tripping over the license when developing for business clients.
Regards,
David
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
