|
»
svnjava provider and maven scm
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
svnjava provider and maven scm
by olamy-2
::
Rate this Message:
Hi,
As we don't distribute the svnkit (it's only a dependency available in the central repo), why we can't make a release of this provider ? Any objections to move the sandbox module in trunk ? Thanks, -- Olivier |
|
|
Re: svnjava provider and maven scm
by Jason van Zyl-5
::
Rate this Message:
If the license is not one that the ASF accepts then we can't really
dodge the issue by saying that it's only in the POM. On 18-Mar-09, at 5:22 PM, Olivier Lamy wrote: > Hi, > As we don't distribute the svnkit (it's only a dependency available in > the central repo), why we can't make a release of this provider ? > Any objections to move the sandbox module in trunk ? > > Thanks, > -- > Olivier Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. |
|
|
Re: svnjava provider and maven scm
by olamy-2
::
Rate this Message:
Hi,
Ok. It's was not really clear for me. Thanks for clarification, -- Olivier 2009/3/19 Jason van Zyl <jvanzyl@...>: > If the license is not one that the ASF accepts then we can't really dodge > the issue by saying that it's only in the POM. > > On 18-Mar-09, at 5:22 PM, Olivier Lamy wrote: > >> Hi, >> As we don't distribute the svnkit (it's only a dependency available in >> the central repo), why we can't make a release of this provider ? >> Any objections to move the sandbox module in trunk ? >> >> Thanks, >> -- >> Olivier > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > To do two things at once is to do neither. > > -—Publilius Syrus, Roman slave, first century B.C. > > |
|
|
Re: svnjava provider and maven scm
by Jason van Zyl-5
::
Rate this Message:
On 19-Mar-09, at 1:25 AM, Olivier Lamy wrote:
> Hi, > Ok. It's was not really clear for me. > Technically we are not redistributing anything and we can ask the board for clarification because in the strictest sense we do not redistribute. But I think folks here would interpret a dependency in your POM as being equivalent. > Thanks for clarification, > -- > Olivier > > 2009/3/19 Jason van Zyl <jvanzyl@...>: >> If the license is not one that the ASF accepts then we can't really >> dodge >> the issue by saying that it's only in the POM. >> >> On 18-Mar-09, at 5:22 PM, Olivier Lamy wrote: >> >>> Hi, >>> As we don't distribute the svnkit (it's only a dependency >>> available in >>> the central repo), why we can't make a release of this provider ? >>> Any objections to move the sandbox module in trunk ? >>> >>> Thanks, >>> -- >>> Olivier >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> ---------------------------------------------------------- >> >> To do two things at once is to do neither. >> >> -—Publilius Syrus, Roman slave, first century B.C. >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- |
|
|
|
|
|
Re: svnjava provider and maven scm
by brettporter
::
Rate this Message:
On 19/03/2009, at 7:29 PM, Jason van Zyl wrote: > On 19-Mar-09, at 1:25 AM, Olivier Lamy wrote: > >> Hi, >> Ok. It's was not really clear for me. >> There is precedent - we grandfathered in Checkstyle which is LGPL as it is just a dependency of a plugin, which we don't actually distribute. The general talk - though not confirmed - is that optional dependencies that the user must obtain themselves could be ok. There isn't a legal problem with the combination, but rather a policy one that you don't distribute something that is essentially useless without a dependency of a stronger license. We should ask, but I personally think this is ok, as long as: - it is not made the default provider - instructions on the site about how to use it spell out that it requires the dependency and that it is not under the AL - we don't bundle and distribute > > Technically we are not redistributing anything and we can ask the > board for clarification because in the strictest sense we do not > redistribute. But I think folks here would interpret a dependency in > your POM as being equivalent. No need to ask the board, you can file a request here: https://issues.apache.org/jira/browse/LEGAL Cheers, Brett -- Brett Porter brett@... http://blogs.exist.com/bporter/ |
|
|
Re: svnjava provider and maven scm
by Jason van Zyl-5
::
Rate this Message:
From my experience asking anyone about anything legal has never been
resolved in any timely manner. Whether grand fathered or anything else. Discussions have gone on for a very long time. Olivier if you want to release it then I would just taking it to mojo and then there are no issues. On 19-Mar-09, at 5:12 AM, Brett Porter wrote: > > On 19/03/2009, at 7:29 PM, Jason van Zyl wrote: > >> On 19-Mar-09, at 1:25 AM, Olivier Lamy wrote: >> >>> Hi, >>> Ok. It's was not really clear for me. >>> > > There is precedent - we grandfathered in Checkstyle which is LGPL as > it is just a dependency of a plugin, which we don't actually > distribute. > > The general talk - though not confirmed - is that optional > dependencies that the user must obtain themselves could be ok. There > isn't a legal problem with the combination, but rather a policy one > that you don't distribute something that is essentially useless > without a dependency of a stronger license. > > We should ask, but I personally think this is ok, as long as: > - it is not made the default provider > - instructions on the site about how to use it spell out that it > requires the dependency and that it is not under the AL > - we don't bundle and distribute > >> >> Technically we are not redistributing anything and we can ask the >> board for clarification because in the strictest sense we do not >> redistribute. But I think folks here would interpret a dependency >> in your POM as being equivalent. > > No need to ask the board, you can file a request here: https://issues.apache.org/jira/browse/LEGAL > > Cheers, > Brett > > -- > Brett Porter > brett@... > http://blogs.exist.com/bporter/ > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- |
|
|
Re: svnjava provider and maven scm
by olamy-2
::
Rate this Message:
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. -- Olivier 2009/3/19 Jason van Zyl <jvanzyl@...>: > From my experience asking anyone about anything legal has never been > resolved in any timely manner. > > Whether grand fathered or anything else. Discussions have gone on for a very > long time. > > Olivier if you want to release it then I would just taking it to mojo and > then there are no issues. > > On 19-Mar-09, at 5:12 AM, Brett Porter wrote: > >> >> On 19/03/2009, at 7:29 PM, Jason van Zyl wrote: >> >>> On 19-Mar-09, at 1:25 AM, Olivier Lamy wrote: >>> >>>> Hi, >>>> Ok. It's was not really clear for me. >>>> >> >> There is precedent - we grandfathered in Checkstyle which is LGPL as it is >> just a dependency of a plugin, which we don't actually distribute. >> >> The general talk - though not confirmed - is that optional dependencies >> that the user must obtain themselves could be ok. There isn't a legal >> problem with the combination, but rather a policy one that you don't >> distribute something that is essentially useless without a dependency of a >> stronger license. >> >> We should ask, but I personally think this is ok, as long as: >> - it is not made the default provider >> - instructions on the site about how to use it spell out that it requires >> the dependency and that it is not under the AL >> - we don't bundle and distribute >> >>> >>> Technically we are not redistributing anything and we can ask the board >>> for clarification because in the strictest sense we do not redistribute. But >>> I think folks here would interpret a dependency in your POM as being >>> equivalent. >> >> No need to ask the board, you can file a request here: >> https://issues.apache.org/jira/browse/LEGAL >> >> Cheers, >> Brett >> >> -- >> Brett Porter >> brett@... >> http://blogs.exist.com/bporter/ >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > > |
|
|
Re: svnjava provider and maven scm
by brettporter
::
Rate this Message:
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: https://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 brett@... http://blogs.exist.com/bporter/ |
|
|
Re: svnjava provider and maven scm
by Jason van Zyl-5
::
Rate this Message:
On 19-Mar-09, at 8:17 AM, Olivier Lamy wrote:
The svn library is not optional for this component to work. You require it to run. SVNKit and that's not LGPL, it's a license we've never validated here. It's a custom license called the TMate Open Source License. Brett's proposal is not fine. You may not like the way the legal process is here but you can't end-run the safe guards in place by saying something is optional when it clearly is not. And then trying to draw an analogy to a project where the license isn't even the same and a completely custom one at that. Ask Apache legal. Explain to them you're marking optional what isn't and show them the TMate license and see what they tell you.
Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven ---------------------------------------------------------- |
|
|
Re: svnjava provider and maven scm
by olamy-2
::
Rate this Message:
Hi,
Not in mojo but here : http://xircles.codehaus.org/projects/svn4j ? a new path : https://svn.codehaus.org/svn4j/maven-scm-provider-svnjava/ -- Olivier 2009/3/20 Brett Porter <brett@...>: > > 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: https://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 > brett@... > http://blogs.exist.com/bporter/ > > |
|
|
Re: svnjava provider and maven scm
by Jason van Zyl-5
::
Rate this Message:
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 : https://svn.codehaus.org/svn4j/maven-scm-provider- > svnjava/ > > -- > Olivier > > 2009/3/20 Brett Porter <brett@...>: >> >> 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: https://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 >> brett@... >> 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 |
|
|
Re: svnjava provider and maven scm
by olamy-2
::
Rate this Message:
only maven-scm-provider-svnjava
-- Olivier 2009/3/20 Jason van Zyl <jvanzyl@...>: > 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 : https://svn.codehaus.org/svn4j/maven-scm-provider-svnjava/ >> >> -- >> Olivier >> >> 2009/3/20 Brett Porter <brett@...>: >>> >>> 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: https://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 >>> brett@... >>> 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 > > |
|
|
Re: svnjava provider and maven scm
by Jason van Zyl-5
::
Rate this Message:
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 <jvanzyl@...>: >> 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 : https://svn.codehaus.org/svn4j/maven-scm-provider-svnjava/ >>> >>> -- >>> Olivier >>> >>> 2009/3/20 Brett Porter <brett@...>: >>>> >>>> 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: https://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 >>>> brett@... >>>> 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 |
|
|
Re: svnjava provider and maven scm
by olamy-2
::
Rate this Message:
So I have moved back the provider to sandbox and start a fork here [1]
If someone want to have karma ping me. -- Olivier [1] http://code.google.com/p/maven-scm-provider-svnjava/ 2009/3/20 Jason van Zyl <jvanzyl@...>: > 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 <jvanzyl@...>: >>> >>> 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 : https://svn.codehaus.org/svn4j/maven-scm-provider-svnjava/ >>>> >>>> -- >>>> Olivier >>>> >>>> 2009/3/20 Brett Porter <brett@...>: >>>>> >>>>> 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: https://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 >>>>> brett@... >>>>> 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 > > |
|
|
Re: svnjava provider and maven scm
by brettporter
::
Rate this Message:
On 21/03/2009, at 6:38 AM, Jason van Zyl wrote: > 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. > I'm not quite sure what you're saying exactly. We seem to have the same understanding of the license at least (that's exactly what I said in the issue), it is totally viral and forces you to redistribute your source code if you use it (it is based on distribution). My suggestion was how we could offer our source code, without the library, and give suitable warning on the impact of turning it on as an optional bit of Maven SCM for those that can use the license. Regardless, I closed the issue since Olivier moved it out. - Brett -- Brett Porter brett@... http://blogs.exist.com/bporter/ |
|
|
Re: svnjava provider and maven scm
by brettporter
::
Rate this Message:
On 21/03/2009, at 9:05 AM, Olivier Lamy wrote:
> So I have moved back the provider to sandbox and start a fork here [1] > If someone want to have karma ping me. I suggest we just remove the provider from the sandbox then rather than have the ambiguity. - Brett -- Brett Porter brett@... http://blogs.exist.com/bporter/ |
|
|
Re: svnjava provider and maven scm
by olamy-2
::
Rate this Message:
done. there is now only a README.TXT
(https://svn.apache.org/repos/asf/maven/sandbox/trunk/scm/README.TXT) -- Olivier 2009/3/21 Brett Porter <brett@...>: > On 21/03/2009, at 9:05 AM, Olivier Lamy wrote: > >> So I have moved back the provider to sandbox and start a fork here [1] >> If someone want to have karma ping me. > > I suggest we just remove the provider from the sandbox then rather than have > the ambiguity. > > - Brett > > -- > Brett Porter > brett@... > http://blogs.exist.com/bporter/ > > |
| Free embeddable forum powered by Nabble | Forum Help |
