You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-user@jakarta.apache.org by Peter Morgan <pm...@jcoverage.com> on 2003/05/28 17:59:00 UTC
jcoverage/gpl
Hi,
We have released a GPL Java Code Coverage tool, called: jcoverage.
Available from, http://jcoverage.com. Why is this of interest to the
subscribers of bcel-user? jcoverage is written using the BCEL library,
it is GPL software, and could be an interesting example for BCEL users
to study.
We use BCEL to insert instrumentation into every instruction that has an
associated line number. We also record the position of conditional
branches so that we can determine branch coverage.
Our GPL source code is available from:
http://jcoverage.com/download/jcoverage.html. You can browse our source
repository via http://jcoverage.bkbits.net/. We welcome, comments and/or
contributions.
jcoverage is also available under a commercial license for the
instrumentation of non-GPL applications.
Regards,
Peter.
--
Peter Morgan
jcoverage ltd
+44 1423 526 426
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by Peter Morgan <pm...@jcoverage.com>.
[I didn't mean to hijack this list for a licensing discussion. Sorry]
On Thu, 2003-05-29 at 21:16, David Hovemeyer wrote:
> On Thu, May 29, 2003 at 08:49:47PM +0100, Peter Morgan wrote:
> > As the copyright holder we specifically make exceptions to the GPL where
> > the instrumented application is either licensed under the GPL or
> > licensed under an OSI license. Our licensing policy is described here:
> > http://jcoverage.com/license.html.
>
> According to the GPL:
>
> "The act of running the Program is not restricted"
> (item 0 in "Terms and Conditions")
>
> "You may not impose any further restrictions on the recipients'
> exercise of the rights granted herein."
> (item 6 in "Terms and Conditions")
>
> Therefore, it seems to me that you cannot license your application
> under the GPL *and* impose restrictions on the use of your program.
>
> > The principle reason for choosing the GPL is for revenue protection.
> > While we are happy for any OSI licensed application to be instrumented
> > with jcoverage, we do not want commercial licensed applications to be
> > instrumented without having purchased the commercially licensed version
> > of jcoverage.
>
> I don't think the GPL will allow you to do this. You should probably
> write your own license.
The model that we are basically trying to follow is that of MySQL. Could
you please explain why
http://www.mysql.com/products/licensing.html is any different to our
model.
Thanks,
Peter.
--
Peter Morgan
jcoverage ltd
+44 1423 526 426
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by David Hovemeyer <da...@cs.umd.edu>.
On Thu, May 29, 2003 at 08:49:47PM +0100, Peter Morgan wrote:
> As the copyright holder we specifically make exceptions to the GPL where
> the instrumented application is either licensed under the GPL or
> licensed under an OSI license. Our licensing policy is described here:
> http://jcoverage.com/license.html.
According to the GPL:
"The act of running the Program is not restricted"
(item 0 in "Terms and Conditions")
"You may not impose any further restrictions on the recipients'
exercise of the rights granted herein."
(item 6 in "Terms and Conditions")
Therefore, it seems to me that you cannot license your application
under the GPL *and* impose restrictions on the use of your program.
> The principle reason for choosing the GPL is for revenue protection.
> While we are happy for any OSI licensed application to be instrumented
> with jcoverage, we do not want commercial licensed applications to be
> instrumented without having purchased the commercially licensed version
> of jcoverage.
I don't think the GPL will allow you to do this. You should probably
write your own license.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by Peter Morgan <pm...@jcoverage.com>.
On Thu, 2003-05-29 at 19:10, Berin Loritsch wrote:
> Its a neat idea, but GPL mixed with BCEL makes me shiver. If you
> automatically alter my compiled code, does that mean I have to release
> my code using GPL?
As the copyright holder we specifically make exceptions to the GPL where
the instrumented application is either licensed under the GPL or
licensed under an OSI license. Our licensing policy is described here:
http://jcoverage.com/license.html.
In no way is it our intention to prevent any OSI licensed application
from being instrumented with the GPL version of jcoverage. Instrumenting
an OSI licensed application with the GPL version of jcoverage does not
cause that instrumented application to be licensed under the GPL.
> If JCoverage is using BCEL, does that pose a problem for BCEL?
I am no lawyer, I write code :), but my reading of
http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat, is that we
can link with "GPL-incompatible" libraries, without causing that library
to become GPL. As the copyright holder we can make exceptions to the GPL
for such purposes, jcoverage is specifically designed to work with BCEL,
log4j, junit, oro and getopt.
> What about at the very least using LGPL? It is far lest strict.
The principle reason for choosing the GPL is for revenue protection.
While we are happy for any OSI licensed application to be instrumented
with jcoverage, we do not want commercial licensed applications to be
instrumented without having purchased the commercially licensed version
of jcoverage.
Regards,
Peter.
--
Peter Morgan
jcoverage ltd
+44 1423 526 426
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by Berin Loritsch <bl...@apache.org>.
Peter Morgan wrote:
> Hi,
>
> We have released a GPL Java Code Coverage tool, called: jcoverage.
> Available from, http://jcoverage.com. Why is this of interest to the
> subscribers of bcel-user? jcoverage is written using the BCEL library,
> it is GPL software, and could be an interesting example for BCEL users
> to study.
Its a neat idea, but GPL mixed with BCEL makes me shiver. If you
automatically alter my compiled code, does that mean I have to release
my code using GPL?
If JCoverage is using BCEL, does that pose a problem for BCEL?
What about at the very least using LGPL? It is far lest strict.
>
> We use BCEL to insert instrumentation into every instruction that has an
> associated line number. We also record the position of conditional
> branches so that we can determine branch coverage.
>
> Our GPL source code is available from:
> http://jcoverage.com/download/jcoverage.html. You can browse our source
> repository via http://jcoverage.bkbits.net/. We welcome, comments and/or
> contributions.
>
> jcoverage is also available under a commercial license for the
> instrumentation of non-GPL applications.
>
> Regards,
> Peter.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter Morgan wrote:
> We have released a GPL Java Code Coverage tool, called: jcoverage.
The web site reads
Commercial users may evaluate jcoverage for a period not exceeding
15 days using the GPL version. Thereafter commercial users must
either stop using the GPL version of jcoverage, or purchase the
non-GPL licensed version.
While the intent is understandable, the license for the program
with these strings attached is no longer GPL. You should consult
a real and experienced lawyer on this, the FSF can become quite
unhappy about misuse of the term "GPL".
Also the need to have a *commercial* tool (read: pay money) in order
to get the source can be seen as a contradiction to GPL terms, you
might want to think about this too.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org