You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <ou...@kompuart.pl> on 2003/02/03 10:55:35 UTC
software licensing
The Apache license allows to use cocoon in commercial products. Usually
commercial products are licensed for access ( per computer or a number of
floating licenses ). Is there any way that cocoon application could be
licensed too? The customer buys 10 licenses which allows to have at least 10
sessions opened on the server. Maybe it is stupid for web application, but for
normal applications using cocoon as data provider it is not. Currently you
have to license your system on client basis.
Is this possible ?
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@vip.net.pl _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote:
...
>>But if I'm going to fork Cocoon, I'm going to call it "Boboom" anyhow, so?
>
> Baboon, perhaps??
ROTFL :,-)))
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Wed, 5 Feb 2003, Niclas Hedhman wrote:
> Are you saying I can't sell Cocoon as-is as an off-the-shelf product, and have
> support included in the package???
Yes; you -can- give away, rent out, sell 'Cocoon' as is, and simply call
it 'Cocoon' as long as you have not modified it in any way.
That -not-modified-in-any-way- is the key point.
Note that you canot claim you wrote it or that yours is the only official
vesion; hence it cannot be be 'Acme Cocoon' (assuming the company is
called Acme) or 'The Official Cocoon' version.
See for example:
http://www.apple.com/server/web.html
for a company who carefully portrays things as they are.
Other common approach, e.g. IBM, are adding a 'powered by Cocoon' or
'powered by Apache' to the end of their product name (e.g. Websphere).
The latter is mostly used when the company ships a version with
modifications; which is generally the case - as to make it more
attractive for a certain market segment from which the company hopes to
extract money.
But as a general guideline; only call it Cocoon if you have not changed a
single bit (i.e. think MD5's).
But even then always check the license with a lawyer in your own country
before selling and when in doubt contact apache@apache.org (see the
license for the address) for permission. Which we give out all the time.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 05 February 2003 11:10, Pier Fumagalli wrote:
> On 5/2/03 2:54, "Niclas Hedhman" <ni...@hedhman.org> wrote:
> > On Monday 03 February 2003 17:55, Leszek Gawron wrote:
> >> The Apache license allows to use cocoon in commercial products.
> >
> > The Apache Gods,
>
> Err... Pre-1999 BSD Gods <http://opensource.org/licenses/bsd-license.php>
Wow, the Gods of Gods!!!!
> > who wrote the License, really understood what "freedom"
> > means. With that came you being allowed to do practically anything you
> > like with the product, OSS or commercially.
>
> Nope, you CAN'T use our name. For example, if you want to use the "Cocoon"
> name in anything related to what we do, ONLY the Cocoon PMC (you) can
> decide on whether to grant that or not.
I said _practically_.
Are you saying I can't sell Cocoon as-is as an off-the-shelf product, and have
support included in the package???
Well, I believe that is happening all over the place with Apache products
(albeit I don't know of any Cocoon offerings yet), and I don't think the PMCs
have been involved...
> That's why for R.M. Stallman our Apache license is not "free", he thinks
> that <http://www.gnu.org/philosophy/bsd.html>
Well, his idea of "freedom" is what I call "health-free" with his viral
concepts. Obviously he thinks that everyone has an "automated refill" feature
on their bank account, since no software developer should make a living...
Ooops, now I am getting personal again.
> But if I'm going to fork Cocoon, I'm going to call it "Boboom" anyhow, so?
Baboon, perhaps??
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Heads Up] Deprecation Resolution and Future Concerns
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
>>What this means is that in addition to providing binary compatibility
>>with all your users, the deprecation messages from Javac will reflect
>>Cocoon deprecations.
>
> How does this impact the changes requiring Stephen to convert CM to SM for
> James? Or doesn't it?
it doesn't at all. This change is in the javadocs only, replacing
'@deprecated' with '<span style="color: red;"></span>'.
>>Excalibur Concurrent has been stopped completely, and we are using
>>Doug Lea's Util.Concurrent library.
>
> Are you exposing util.concurrent, or are you hiding it underneath?
we are not exposing it. We are simply moving some avalon packages which
used to use the avalon threadpool implementation (fortress, ECM) to use
Doug's threadpool implementation.
> What
> impact does this have on those of us using your threadpools?
none. The current avalon-excalibur and avalon-cornerstone threadpools
are of lower quality than Doug's, apparently (I haven't done much
testing myself). Thus we do want to encourage people who use the
avalon-produced threadpools to move away from them and refactor to use
doug's library. We are still backing the avalon-produced threadpools and
they will receive full support.
> I am familar with d.l.u.c and JSR 166. I'm just concerned about short term
> migration issues.
If your current application works snappy with the current threadpools,
there is nothing to worry about. You don't need to migrate in the short
term. Long term, I'm confident a migration path can/shall be provided if
neccessary.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Heads Up] Deprecation Resolution and Future Concerns
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
>>What this means is that in addition to providing binary compatibility
>>with all your users, the deprecation messages from Javac will reflect
>>Cocoon deprecations.
>
>
> How does this impact the changes requiring Stephen to convert CM to SM for
> James? Or doesn't it?
SM is the direction of all future efforts. We want people to to migrate
to SM. However concerning the nature of the complaints from the Cocoon
crowd where they do specialized containers, we had to use a soft
deprecation so as not to unnecessarily scare their users.
>>Excalibur Concurrent has been stopped completely, and we are using
>>Doug Lea's Util.Concurrent library.
>
>
> Are you exposing util.concurrent, or are you hiding it underneath? What
> impact does this have on those of us using your threadpools?
It is largely hidden underneath. You have two choices for threadpools.
You can use the version in Excalibur, or you can use the version in
util.concurrent.
> I am familar with d.l.u.c and JSR 166. I'm just concerned about short term
> migration issues.
We do have the library available for those projects who cannot quickly
migrate. We do understand those issues. The Avalon team could not
provide anything as high quality as Doug Lea's library, nor could we
effectively maintain what we had. Our users deserve better. To
deliver, we need to focus on our competencies.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Heads Up] Deprecation Resolution and Future Concerns
Posted by "Noel J. Bergman" <no...@devtech.com>.
> What this means is that in addition to providing binary compatibility
> with all your users, the deprecation messages from Javac will reflect
> Cocoon deprecations.
How does this impact the changes requiring Stephen to convert CM to SM for
James? Or doesn't it?
> Excalibur Concurrent has been stopped completely, and we are using
> Doug Lea's Util.Concurrent library.
Are you exposing util.concurrent, or are you hiding it underneath? What
impact does this have on those of us using your threadpools?
I am familar with d.l.u.c and JSR 166. I'm just concerned about short term
migration issues.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
[Heads Up] Deprecation Resolution and Future Concerns
Posted by Berin Loritsch <bl...@apache.org>.
The Avalon team voted in favor of using a softer form of deprecation for
the org.apache.avalon.framework.component package. The Recomposable
class remains deprecated, but this should not affect any Cocoon users.
No known container supports it, and it is a bad design that was carried
forward from the Avalon 3.x days.
What this means is that in addition to providing binary compatibility
with all your users, the deprecation messages from Javac will reflect
Cocoon deprecations.
We will be releasing the Avalon projects a step at a time. Each step
will be compatible with the currently released versions of all the
software. We will have a new released ECM in the very near future
(hopefully).
The new ECM will have some changes, some for the better and some that
might cause some changes for you. One change for the better is that
we backported the *-complete-*.jar feature from Fortress. That means
all Excalibur JARS necessary for ECM to run will be in one large JAR
file. The CVS version does not use Excalibur Collections or Excalibur
Concurrent any longer. The Avalon team will make one last release
of those projects with all the classes deprecated. It will allow you
to maintain backward compatibility while pointing your users to
higher quality libraries that are maintained better.
Excalibur Collections has been merged into Commons Collections-2.1,
and as a result the class names have changed. All the deprecation
messages point you to a compatible class.
Excalibur Concurrent has been stopped completely, and we are using
Doug Lea's Util.Concurrent library. That is the library that will
perform the basis of the new JDK 1.5 threading primitives. It is
in the public domain, so it should not pose any licensing issues
for anyone.
You will still have to include the JARs for projects outside the
scope of ECM's direct dependencies like SourceResolver which now
works in both ECM and Fortress environments.
If you can furnish a list of all the Cocoon dependencies to the
Avalon Developers list (avalon-dev@jakarta.apache.org) we can
incorporate them into the Excalibur Phase I release.
Your help will be greatly appreciated, and in the end will directly
help you.
-- The Avalon Team.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
[Heads Up] Deprecation Resolution and Future Concerns
Posted by Berin Loritsch <bl...@apache.org>.
The Avalon team voted in favor of using a softer form of deprecation for
the org.apache.avalon.framework.component package. The Recomposable
class remains deprecated, but this should not affect any Cocoon users.
No known container supports it, and it is a bad design that was carried
forward from the Avalon 3.x days.
What this means is that in addition to providing binary compatibility
with all your users, the deprecation messages from Javac will reflect
Cocoon deprecations.
We will be releasing the Avalon projects a step at a time. Each step
will be compatible with the currently released versions of all the
software. We will have a new released ECM in the very near future
(hopefully).
The new ECM will have some changes, some for the better and some that
might cause some changes for you. One change for the better is that
we backported the *-complete-*.jar feature from Fortress. That means
all Excalibur JARS necessary for ECM to run will be in one large JAR
file. The CVS version does not use Excalibur Collections or Excalibur
Concurrent any longer. The Avalon team will make one last release
of those projects with all the classes deprecated. It will allow you
to maintain backward compatibility while pointing your users to
higher quality libraries that are maintained better.
Excalibur Collections has been merged into Commons Collections-2.1,
and as a result the class names have changed. All the deprecation
messages point you to a compatible class.
Excalibur Concurrent has been stopped completely, and we are using
Doug Lea's Util.Concurrent library. That is the library that will
perform the basis of the new JDK 1.5 threading primitives. It is
in the public domain, so it should not pose any licensing issues
for anyone.
You will still have to include the JARs for projects outside the
scope of ECM's direct dependencies like SourceResolver which now
works in both ECM and Fortress environments.
If you can furnish a list of all the Cocoon dependencies to the
Avalon Developers list (avalon-dev@jakarta.apache.org) we can
incorporate them into the Excalibur Phase I release.
Your help will be greatly appreciated, and in the end will directly
help you.
-- The Avalon Team.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Tony Collen <tc...@neuagency.com>.
On Wed, 5 Feb 2003, Sylvain Wallez wrote:
> Pier Fumagalli wrote:
>
> >
> >But if I'm going to fork Cocoon, I'm going to call it "Boboom" anyhow, so?
> >:-) :-) :-) :-)
> >
> >
>
> Check out Popoon, a Cocoon clone in PHP at
> http://www.bitflux.ch/developer/cms/popoon.html !!
Man, this is just too close to Poopoon. ;^)
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Pier Fumagalli wrote:
>
>But if I'm going to fork Cocoon, I'm going to call it "Boboom" anyhow, so?
>:-) :-) :-) :-)
>
>
Check out Popoon, a Cocoon clone in PHP at
http://www.bitflux.ch/developer/cms/popoon.html !!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 5/2/03 2:54, "Niclas Hedhman" <ni...@hedhman.org> wrote:
> On Monday 03 February 2003 17:55, Leszek Gawron wrote:
>> The Apache license allows to use cocoon in commercial products.
>
> The Apache Gods,
Err... Pre-1999 BSD Gods <http://opensource.org/licenses/bsd-license.php>
> who wrote the License, really understood what "freedom"
> means. With that came you being allowed to do practically anything you like
> with the product, OSS or commercially.
Nope, you CAN'T use our name. For example, if you want to use the "Cocoon"
name in anything related to what we do, ONLY the Cocoon PMC (you) can decide
on whether to grant that or not.
That's why for R.M. Stallman our Apache license is not "free", he thinks
that <http://www.gnu.org/philosophy/bsd.html>
Pier
But if I'm going to fork Cocoon, I'm going to call it "Boboom" anyhow, so?
:-) :-) :-) :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 February 2003 17:55, Leszek Gawron wrote:
> The Apache license allows to use cocoon in commercial products.
The Apache Gods, who wrote the License, really understood what "freedom"
means. With that came you being allowed to do practically anything you like
with the product, OSS or commercially.
So feel free to include Cocoon in any commercial offering, embedded in other
products, sold by itself with support or whatever.
If you need to restrict the access to Cocoon for commercial reasons, then you
have to work that out yourself.
Niclas
> Usually
> commercial products are licensed for access ( per computer or a number of
> floating licenses ). Is there any way that cocoon application could be
> licensed too? The customer buys 10 licenses which allows to have at least
> 10 sessions opened on the server. Maybe it is stupid for web application,
> but for normal applications using cocoon as data provider it is not.
> Currently you have to license your system on client basis.
>
> Is this possible ?
> ouzo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Leszek Gawron wrote:
>
>> The Apache license allows to use cocoon in commercial products. Usually
>> commercial products are licensed for access ( per computer or a
>> number of
>> floating licenses ). Is there any way that cocoon application could be
>> licensed too? The customer buys 10 licenses which allows to have at
>> least 10
>> sessions opened on the server. Maybe it is stupid for web
>> application, but for
>> normal applications using cocoon as data provider it is not.
>> Currently you
>> have to license your system on client basis.
>> Is this possible ?
>
>
> There is (obviously) no facility for restricting access to cocoon, if
> you plan to sell a service on top of it, you have to write your own
> code for that.
>
> How? I have no idea and, to be honest, I don't care.
Yep. And remember that this is a list about open-source software that is
available for free. So this may not be the best place to ask...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: software licensing
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> The Apache license allows to use cocoon in commercial products. Usually
> commercial products are licensed for access ( per computer or a number of
> floating licenses ). Is there any way that cocoon application could be
> licensed too? The customer buys 10 licenses which allows to have at least 10
> sessions opened on the server. Maybe it is stupid for web application, but for
> normal applications using cocoon as data provider it is not. Currently you
> have to license your system on client basis.
>
> Is this possible ?
There is (obviously) no facility for restricting access to cocoon, if
you plan to sell a service on top of it, you have to write your own code
for that.
How? I have no idea and, to be honest, I don't care.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org