Licensing
0 views
Skip to first unread message
Carlos Averett
Apr 26, 2008, 4:40:45 PM4/26/08
to php-outline
Hello,
I definately like outline, and the performance is hard to beat.
Unfortunately, the use of the GPL makes it very difficult to use in
many projects.
As an example, I have a project (phpCerts) - a PHP Certificate
Authority - currently in development. It does a number of things that
available CAs don't, providing for easy use of smart cards, chained
CAs, etc.
Because this is targeted at a corporate environment, it is expected
that many of the users will not run it themselves, but rather will
have it provided by a consultant/service provider. As such, it's under
the "University of Illinois/NSCA" license (http://www.opensource.org/
licenses/UoI-NCSA.php), which basically states:
- Don't remove copyright notices
- Don't use my name to endorse or promote derivitive works
- No warranties
All in all, a very friendly license. As this license isn't viral in
nature, the software may be combined with other components as needed,
including (for example) propreitary technologies for things like RSA
SecureID (hardware tokens with a changing number). As there are no
open-source ways to do many of these things (I've looked!), this
provides the maximum flexibility for the users.
Unfortunately, a GPL template engine requires the entire derived work
to be GPL - making it impossible to use with non-gpl code. If the
code cannot be distributed under the GPL, derived works containing non-
GPL and GPL code may not be distributed. This means that my code is
incompatible with the GPL, as the anti-promotion clause is an
additional restriction, and thus incompatible with the GPL.
For a piece of software intended primarily as a component, it makes
more sense to use a license like the LGPL - this way, changes to the
component have to be open source, but things using it do not. In
fact, this is why the LGPL was first called the Library Gnu Public
License. Savant, Template Lite, and Smarty are all distributed under
the LGPL.
A lot of this depends on your goals - personally, I like to maximize
freedom for my users. They are free to do closed-source additions to
my code, should they wish. They are also free to add closed-source
additions to my software, which is sometimes necessary to maximize
functionality. Because the copyright notices must remain intact,
users are always free to get the code I distributed. This is why I
use the NSCA license.
Some projects prefer to remove the ability to close the source on
additions (in order to preserve the freedoms of those who get the
software second-hand), and use a license like the LGPL instead.
I definately like outline, and the performance is hard to beat.
Unfortunately, the use of the GPL makes it very difficult to use in
many projects.
As an example, I have a project (phpCerts) - a PHP Certificate
Authority - currently in development. It does a number of things that
available CAs don't, providing for easy use of smart cards, chained
CAs, etc.
Because this is targeted at a corporate environment, it is expected
that many of the users will not run it themselves, but rather will
have it provided by a consultant/service provider. As such, it's under
the "University of Illinois/NSCA" license (http://www.opensource.org/
licenses/UoI-NCSA.php), which basically states:
- Don't remove copyright notices
- Don't use my name to endorse or promote derivitive works
- No warranties
All in all, a very friendly license. As this license isn't viral in
nature, the software may be combined with other components as needed,
including (for example) propreitary technologies for things like RSA
SecureID (hardware tokens with a changing number). As there are no
open-source ways to do many of these things (I've looked!), this
provides the maximum flexibility for the users.
Unfortunately, a GPL template engine requires the entire derived work
to be GPL - making it impossible to use with non-gpl code. If the
code cannot be distributed under the GPL, derived works containing non-
GPL and GPL code may not be distributed. This means that my code is
incompatible with the GPL, as the anti-promotion clause is an
additional restriction, and thus incompatible with the GPL.
For a piece of software intended primarily as a component, it makes
more sense to use a license like the LGPL - this way, changes to the
component have to be open source, but things using it do not. In
fact, this is why the LGPL was first called the Library Gnu Public
License. Savant, Template Lite, and Smarty are all distributed under
the LGPL.
A lot of this depends on your goals - personally, I like to maximize
freedom for my users. They are free to do closed-source additions to
my code, should they wish. They are also free to add closed-source
additions to my software, which is sometimes necessary to maximize
functionality. Because the copyright notices must remain intact,
users are always free to get the code I distributed. This is why I
use the NSCA license.
Some projects prefer to remove the ability to close the source on
additions (in order to preserve the freedoms of those who get the
software second-hand), and use a license like the LGPL instead.
mindplay.dk
Apr 26, 2008, 5:39:34 PM4/26/08
to php-outline
I will take this under consideration.
Frankly I'm not familiar enough with either the GPL or LGPL licenses
to fully understand what that would mean.
My basic attitude is, I would like my code to be open and freely
available to like minds, who contribute to the growth and development
of the php community.
But my wife is like, "what's in it for me? I missed all these evenings
with my husband, while he was in front of the computer programming
this -- thing. When do you get paid for all the work you've done? Are
you just going to let some company collect on all of your hard work?"
How do I respond to that? :-)
Frankly I'm not familiar enough with either the GPL or LGPL licenses
to fully understand what that would mean.
My basic attitude is, I would like my code to be open and freely
available to like minds, who contribute to the growth and development
of the php community.
But my wife is like, "what's in it for me? I missed all these evenings
with my husband, while he was in front of the computer programming
this -- thing. When do you get paid for all the work you've done? Are
you just going to let some company collect on all of your hard work?"
How do I respond to that? :-)
Carlos Averett
Apr 26, 2008, 6:40:49 PM4/26/08
to php-outline
Well, the big difference between the two is that the GPL applies to
the entire work (use a piece of GPL code, the whole thing must be
GPL), versus the component (use a piece of LGPL code, you must open
source only changes to that library).
As for the "what's in it for me" aspect - there's a (fairly) simple
way to approach that.
With software, there are pretty much two types of revenue models -
sell the software, or sell the support/advertising/etc. There's also
the "don't get paid" model, but those type of people don't usually ask
these sorts of questions. I don't really recommend it.
Selling a template system is going to be a really hard sell,
especially given the competition's LGPL/Free state. It is, however,
possible to sell products built around it, but in that case, the
license of the template system won't really matter much - it will be
the system as a whole that matters.
OTOH, if you go for the "sell the support/advertising/etc." model, you
want as many people using it as possible. Modification is good,
because they might break things, and hey - there's your support! :)
So, a license should be selected that maximizes the users (and revenue
opportunities). Of course, monetizing a template system is still
going to be hard.
My honest recommendation is to use the software as a springboard -
write a couple of testable, reusable components, and throw together
little apps using the template system. Mention that support (or
custom work) is available for a price. Being webapps makes doing a
closed-source approach difficult anyway, so embrace openness.
As for my company - we take our components (multimedia decoders, UPNP
engines, skinning, etc.) and turn them into a variety of software
(picture frames, GPS media players, DirectShow decoders, etc.). We
open-source what we can. Because we leverage existing code, we are
able to support Windows, Linux, iPhone, OS X, Windows CE, Palm, and
Symbian with the same codebase. For webapps, it's even easier - one
PHP script can support all modern browsers.
> > software second-hand), and use a license like the LGPL instead.- Hide quoted text -
>
> - Show quoted text -
the entire work (use a piece of GPL code, the whole thing must be
GPL), versus the component (use a piece of LGPL code, you must open
source only changes to that library).
As for the "what's in it for me" aspect - there's a (fairly) simple
way to approach that.
With software, there are pretty much two types of revenue models -
sell the software, or sell the support/advertising/etc. There's also
the "don't get paid" model, but those type of people don't usually ask
these sorts of questions. I don't really recommend it.
Selling a template system is going to be a really hard sell,
especially given the competition's LGPL/Free state. It is, however,
possible to sell products built around it, but in that case, the
license of the template system won't really matter much - it will be
the system as a whole that matters.
OTOH, if you go for the "sell the support/advertising/etc." model, you
want as many people using it as possible. Modification is good,
because they might break things, and hey - there's your support! :)
So, a license should be selected that maximizes the users (and revenue
opportunities). Of course, monetizing a template system is still
going to be hard.
My honest recommendation is to use the software as a springboard -
write a couple of testable, reusable components, and throw together
little apps using the template system. Mention that support (or
custom work) is available for a price. Being webapps makes doing a
closed-source approach difficult anyway, so embrace openness.
As for my company - we take our components (multimedia decoders, UPNP
engines, skinning, etc.) and turn them into a variety of software
(picture frames, GPS media players, DirectShow decoders, etc.). We
open-source what we can. Because we leverage existing code, we are
able to support Windows, Linux, iPhone, OS X, Windows CE, Palm, and
Symbian with the same codebase. For webapps, it's even easier - one
PHP script can support all modern browsers.
>
> - Show quoted text -
mindplay.dk
Apr 26, 2008, 7:12:18 PM4/26/08
to php-outline
Only problem with that idea is I don't have time to offer support.
Paid or otherwise. I don't need more work.
That wasn't why I created this template engine. If anything, it was
about making less work for myself, not more.
But I will think about it. Although I don't think my wife would think
it's a great idea to give all that work away for someone else to make
profit with. Her point of view is, if someone is going to use my work
for profit, we should agree on a price for the work I've already put
in, and I should license it to you under different terms.
The last thing she would want is for me to make more work for myself.
She's sweet and southern, with a "hippie" attitude, but she wasn't
born yesterday ;-)
Paid or otherwise. I don't need more work.
That wasn't why I created this template engine. If anything, it was
about making less work for myself, not more.
But I will think about it. Although I don't think my wife would think
it's a great idea to give all that work away for someone else to make
profit with. Her point of view is, if someone is going to use my work
for profit, we should agree on a price for the work I've already put
in, and I should license it to you under different terms.
The last thing she would want is for me to make more work for myself.
She's sweet and southern, with a "hippie" attitude, but she wasn't
born yesterday ;-)
mindplay.dk
Apr 27, 2008, 4:27:53 PM4/27/08
to php-outline
By the way, if you're considering Outline for a bigger project, I
should point out the fact that it is not yet recommended for use on
production sites.
For one, it has not yet been tested thoroughly.
For another, the API is not yet formally settled - changes,
potentially major changes, might still happen in the next 1-2 months,
before the first official release version. It's unlikely that the API
will undergo really serious changes at this point, but it is possible.
And lastly, there are currently unresolved problems - one of them
involves concurrency (threading issues) when Outline performs file
writing (updating cache files, writing compiled templates) ... this is
quite a serious issue, which must be resolved before the initial
release. It's something I've spent a lot of time on during the last
couple of weeks, and I am close to settling on a solution, but it has
to be tested carefully before Outline can be safely put to use on
major sites.
should point out the fact that it is not yet recommended for use on
production sites.
For one, it has not yet been tested thoroughly.
For another, the API is not yet formally settled - changes,
potentially major changes, might still happen in the next 1-2 months,
before the first official release version. It's unlikely that the API
will undergo really serious changes at this point, but it is possible.
And lastly, there are currently unresolved problems - one of them
involves concurrency (threading issues) when Outline performs file
writing (updating cache files, writing compiled templates) ... this is
quite a serious issue, which must be resolved before the initial
release. It's something I've spent a lot of time on during the last
couple of weeks, and I am close to settling on a solution, but it has
to be tested carefully before Outline can be safely put to use on
major sites.
Reply all
Reply to author
Forward
0 new messages