Re: svnjava provider and maven scm
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 : > 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 > [email protected] > http://blogs.exist.com/bporter/ > >
Re: svnjava provider and maven scm
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 [email protected] http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
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 [email protected] http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
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 : > 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 : >>> >>> 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 : > > 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 > [email protected] > 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
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 : 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 : 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 [email protected] 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
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 [email protected] http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
On 19-Mar-09, at 8: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. 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. -- Olivier 2009/3/19 Jason van Zyl : 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 [email protected] http://blogs.exist.com/bporter/ Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --
Re: svnjava provider and maven scm
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 [email protected] http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
In fact we are not 'packaging' it, but we 'distribute' it via download links. So from the de iure point this is really edgy. The easiest thing would be to simply ask svnkit folks to give us a consensus letter that we are allowed to use it for maven-scm or even better a general clearance for using it in Apache projects. LieGrue, strub --- Jason van Zyl schrieb am Do, 19.3.2009: > Von: Jason van Zyl > Betreff: Re: svnjava provider and maven scm > An: [email protected] > Datum: Donnerstag, 19. März 2009, 9:29 > 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 : > >> 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
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.
