Brett,
There is no way we accept the Sleepcat license, it's viral. It is also
heavily recommend against using because it can force you to have to
redistribute your source code. That from our IP lawyer who deals with
every day. Please don't dispense legal advice. Everything in law is in
interpretation but there are some accepted interpretation. It's also
unlikely that those contracts are identical unless they are verbatim
and originate from the same country.
On 20-Mar-09, at 8:02 AM, Olivier Lamy wrote:
only maven-scm-provider-svnjava
--
Olivier
2009/3/20 Jason van Zyl <jvan...@sonatype.com>:
That's an old fork of svnkit, not sure you want to put it there. That
project is essentially dead.
On 20-Mar-09, at 1:46 AM, Olivier Lamy wrote:
Hi,
Not in mojo but here : http://xircles.codehaus.org/projects/svn4j ?
a new path : http://svn.codehaus.org/svn4j/maven-scm-provider-svnjava/
--
Olivier
2009/3/20 Brett Porter <br...@apache.org>:
On 20/03/2009, at 2:17 AM, Olivier Lamy wrote:
So the Brett proposal looks fine too.
I can mark the svnjava provider as optionnal and explain why on
the
scm site and explain how to use it.
That was all my opinion, so we should get it confirmed before
release.
Note
that under the current FAQ the Sleepycat license (which this is
equivalent
to), is not allowed for inclusion.
I filed: http://issues.apache.org/jira/browse/LEGAL-45, and
added a
couple
more points on the list about how we can avoid it getting used
without
being
aware of the license - putting it in a separate build profile and
making
sure it is not in the aggregating POM.
It can always go to mojo, but I think it'd be a shame to have to
separate
it, so it's worth asking.
- Brett
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
