Keep in mind that I am not proposing that we bulk-copy from the plexus code. I'm proposing that for classes where (1) there's no drop-in replacement from commons, (2) they are labelled with a Apache license, and (3) they are small and hard to recreate without effectively copying them, that we take them without complex analysis of provenance.
I'm happy to open a ticket if anyone would prefer backup, and I'm happy to shut up if a consensus exists already not to do this. On Mon, Jun 13, 2011 at 9:25 AM, Mark Struberg <[email protected]> wrote: > Well, from the legal pov we are on the safe side because the sources we took > the code from are ALv2. If this ALv2 license tag is not appropriate then we > are still on the safe side and no one could sue us! > > The only thing we would need to do in this case is that we'd have to rewrite > those tiny fractions where a 3rd party could clearly prove his ownership! So > in practice there is imo a kind of reversal of evidence in place thus it's > 'pretty' safe to use that code. Especially since this code is already in the > public domain since many years with the ALv2 sticker on it... > > LieGrue, > strub > > --- On Mon, 6/13/11, Benson Margulies <[email protected]> wrote: > >> From: Benson Margulies <[email protected]> >> Subject: Re: Truly awful code in plexus... >> To: "Maven Developers List" <[email protected]> >> Date: Monday, June 13, 2011, 1:15 PM >> Mark, >> >> I think it appropriate to mix in the scale. I bet you that >> if we >> opened a ticket on legal-discuss that said, 'there's a >> 50-line java >> source file with an Apache license sitting at Codehaus, can >> we >> incorporate it?' that the answer would be yes. >> >> If someone then wanted to show up and specifically claim >> copyright and >> that the licence notice was a usurpation, well, something >> would >> happen. >> >> I'd open the ticket before I'd spend time recoding very >> simple classes >> where the original author might well claim copyright >> infringement of >> any version we came up with anyway. >> >> --benson >> >> >> On Mon, Jun 13, 2011 at 9:03 AM, Mark Struberg <[email protected]> >> wrote: >> > I think there are 2 sides of the story. >> > If you know who applied the ALv2 license to the code >> in question, then you're fine. >> > If you don't have any provenance then you better back >> off from taking the sources. >> > >> > I think it's pretty safe to take ALv2 licensed sources >> from codehaus.org Plexus project, since all the history is >> available and 80% of the committers are Apache committers >> (with an iCLA on file) anyway. >> > >> > LieGrue, >> > strub >> > >> > --- On Mon, 6/13/11, Benson Margulies <[email protected]> >> wrote: >> > >> >> From: Benson Margulies <[email protected]> >> >> Subject: Re: Truly awful code in plexus... >> >> To: "Maven Developers List" <[email protected]> >> >> Date: Monday, June 13, 2011, 12:54 PM >> >> There's an IP principle that is >> >> escaping me here. >> >> >> >> According to the previous answered legal questions >> page, as >> >> I read it, >> >> if you find a small amount of source anywhere, and >> it has >> >> an Apache >> >> license notice on it, you can incorporate it into >> an Apache >> >> project >> >> without any further research into provenance. >> This >> >> discussion seems to >> >> be predicated on a stricter policy, or perhaps on >> some >> >> particular >> >> reason to think that someone grabbed what didn't >> belong to >> >> them, >> >> slapped an Apache notice on it, and committed it >> to this >> >> project. >> >> >> >> ? >> >> >> >> >> >> On Mon, Jun 13, 2011 at 8:48 AM, Olivier Lamy >> <[email protected]> >> >> wrote: >> >> > Hello, >> >> > >> >> > 2011/6/13 Benson Margulies <[email protected]>: >> >> >> Let's be specific about a few classes. >> >> >> >> >> >> CollectionUtil has an @author of olamy >> and an >> >> apache notice, so I >> >> >> grabbed it rather than try to recreate >> it. >> >> > >> >> > Doh I don't remember why it's here :-) . In >> fact not >> >> sure it was for >> >> > Maven (maybe written long time ago for >> continuum ) >> >> > >> >> > Someone know a place where it's used in maven >> source >> >> code ? (sorry as >> >> > usual I have a small memory fooprint :-) ) >> >> > >> >> >> >> >> >> FastMap and CachedMap are grabbed from >> javolution. >> >> We can call the >> >> >> current javolution from the bridge. >> >> >> >> >> >> StringInputStream and StringOutputStream >> are >> >> deprecated, have an >> >> >> Apache 1.1 license, have no obvious >> author, and >> >> known-busted. They are >> >> >> also so trivial that I claim that copying >> their >> >> source for interim >> >> >> compatibility is harmless, given the >> license >> >> notice. >> >> >> >> >> >> StringUtils is a large collection of >> fiddly >> >> functions. Again, an >> >> >> Apache license, and a claim of provenance >> from >> >> Apache Turbine. Do we >> >> >> really need to recreate it due to >> license >> >> considerations? >> >> >> >> >> >> ReaderFactory: has an Apache notice, a >> Maven >> >> committer's name on it. >> >> >> If nothing else, Herve could commit a >> copy of it >> >> to the sandbox and >> >> >> we'd be good to go. >> >> >> >> >> >> SweeperPool: does anything use this? It >> would be >> >> somewhat scary to recreate. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jun 13, 2011 at 5:46 AM, Stephen >> Connolly >> >> >> <[email protected]> >> >> wrote: >> >> >>> It's tempting... but I fear all that >> will >> >> happen is nobody will switch >> >> >>> to the new impl... >> >> >>> >> >> >>> the WHOLE point of this bridge is to >> remove >> >> any dependency on >> >> >>> plexus-utils in core... and how we >> class-load >> >> plexus-utils is IIRC >> >> >>> that we force the core version on all >> plugins >> >> no matter what they >> >> >>> use... so if we remove a deprecated >> method and >> >> a plugin is expecting >> >> >>> it then that plugin breaks. >> >> >>> >> >> >>> On 13 June 2011 10:41, Mark Struberg >> <[email protected]> >> >> wrote: >> >> >>>> Hi! >> >> >>>> >> >> >>>> If those methods are already >> deprecated, >> >> then I'd say we should drop them now. >> >> >>>> >> >> >>>> Most times those methods didn't >> got >> >> deprecated because they are 'unpretty' but because >> they are >> >> seriously flawed. Like missing encoding parameter, >> missing >> >> timezone, not multithreading capable, etc. >> >> >>>> >> >> >>>> So if those methods are >> deprecated for >> >> more than a year now (or < maven-2.2.1 and >> maven-3.0), >> >> then I'd say lets drop them now. >> >> >>>> >> >> >>>> LieGrue, >> >> >>>> strub >> >> >>>> >> >> >>>> --- On Mon, 6/13/11, Stephen >> Connolly >> >> <[email protected]> >> >> wrote: >> >> >>>> >> >> >>>>> From: Stephen Connolly <[email protected]> >> >> >>>>> Subject: Re: Truly awful code >> in >> >> plexus... >> >> >>>>> To: "Maven Developers List" >> <[email protected]> >> >> >>>>> Date: Monday, June 13, 2011, >> 5:55 AM >> >> >>>>> if we knew the provenance of >> the >> >> >>>>> plexus code, yes... but we >> don't >> >> >>>>> >> >> >>>>> - Stephen >> >> >>>>> >> >> >>>>> --- >> >> >>>>> Sent from my Android phone, >> so random >> >> spelling mistakes, >> >> >>>>> random nonsense >> >> >>>>> words and other nonsense are >> a direct >> >> result of using swype >> >> >>>>> to type on the >> >> >>>>> screen >> >> >>>>> On 13 Jun 2011 00:12, >> "Benson >> >> Margulies" <[email protected]> >> >> >>>>> wrote: >> >> >>>>> > If we want to keep the >> broken >> >> behavior of these >> >> >>>>> already @Deprecated >> >> >>>>> > classes, then I'd think >> we'd just >> >> copy them wholesale >> >> >>>>> from plexus to >> >> >>>>> > the bridge. There's no >> advantage >> >> in replacing an old >> >> >>>>> broken version >> >> >>>>> > with a new broken, and >> they're >> >> already deprecated, and >> >> >>>>> the right thing >> >> >>>>> > to do to callers is to >> make them >> >> use modern methods. >> >> >>>>> > >> >> >>>>> > On Sun, Jun 12, 2011 at >> 6:33 PM, >> >> Stephen Connolly >> >> >>>>> > <[email protected]> >> >> >>>>> wrote: >> >> >>>>> >> thanks >> >> >>>>> >> >> >> >>>>> >> - Stephen >> >> >>>>> >> >> >> >>>>> >> --- >> >> >>>>> >> Sent from my Android >> phone, >> >> so random spelling >> >> >>>>> mistakes, random nonsense >> >> >>>>> >> words and other >> nonsense are >> >> a direct result of >> >> >>>>> using swype to type on >> >> >>>>> the >> >> >>>>> >> screen >> >> >>>>> >> On 12 Jun 2011 >> 23:25, "Hervé >> >> BOUTEMY" <[email protected]> >> >> >>>>> wrote: >> >> >>>>> >>> strategy added >> in the >> >> proposal [1], for future >> >> >>>>> reference >> >> >>>>> >>> >> >> >>>>> >>> Regards, >> >> >>>>> >>> >> >> >>>>> >>> Hervé >> >> >>>>> >>> >> >> >>>>> >>> [1] >> >> >>>>> >> >> >> >>>>> https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement >> >> >>>>> >>> >> >> >>>>> >>> Le lundi 13 juin >> 2011, >> >> Stephen Connolly a >> >> >>>>> écrit : >> >> >>>>> >>>> here is my >> thoughts, >> >> for first release we >> >> >>>>> need to have a drop in >> >> >>>>> >>>> replacement >> that >> >> works exactly the same as >> >> >>>>> the original... that gives >> >> >>>>> us >> >> >>>>> >> a >> >> >>>>> >>>> way to kill >> the old >> >> version (otherwise >> >> >>>>> people will just say, "I'm >> not >> >> >>>>> >>>> going to fix >> my code >> >> when it works fine >> >> >>>>> with plexus utils... ok >> maybe >> >> >>>>> >> I'll >> >> >>>>> >>>> fix it >> later") >> >> >>>>> >>>> >> >> >>>>> >>>> we will mark >> every >> >> method and class in the >> >> >>>>> bridge as deprecated, but we >> >> >>>>> >>>> need the >> >> recommendations for each >> >> >>>>> replacement to put in the >> deprecated >> >> >>>>> >>>> tags. >> >> >>>>> >>>> >> >> >>>>> >>>> for the >> second >> >> release we flip the >> >> >>>>> @reproducesplexusbug rule and >> fix >> >> >>>>> all >> >> >>>>> >>>> those test >> cases >> >> >>>>> >>>> >> >> >>>>> >>>> for the >> third >> >> release, everything is >> >> >>>>> deprecated >> >> >>>>> >>>> >> >> >>>>> >>>> - Stephen >> >> >>>>> >>>> >> >> >>>>> >>>> --- >> >> >>>>> >>>> Sent from my >> Android >> >> phone, so random >> >> >>>>> spelling mistakes, random >> >> >>>>> nonsense >> >> >>>>> >>>> words and >> other >> >> nonsense are a direct >> >> >>>>> result of using swype to type >> on >> >> >>>>> >> the >> >> >>>>> >>>> screen >> >> >>>>> >>>> On 12 Jun >> 2011 21:24, >> >> "Benson Margulies" >> >> >>>>> <[email protected]> >> >> >>>>> wrote: >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >> >> >> --------------------------------------------------------------------- >> >> >>>>> >>> To unsubscribe, >> e-mail: >> >> [email protected] >> >> >>>>> >>> For additional >> commands, >> >> e-mail: [email protected] >> >> >>>>> >>> >> >> >>>>> >> >> >> >>>>> > >> >> >>>>> > >> >> >>>>> >> >> >> --------------------------------------------------------------------- >> >> >>>>> > To unsubscribe, e-mail: >> [email protected] >> >> >>>>> > For additional commands, >> e-mail: >> >> [email protected] >> >> >>>>> > >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >> --------------------------------------------------------------------- >> >> >>>> To unsubscribe, e-mail: [email protected] >> >> >>>> For additional commands, e-mail: >> [email protected] >> >> >>>> >> >> >>>> >> >> >>> >> >> >>> >> >> >> --------------------------------------------------------------------- >> >> >>> To unsubscribe, e-mail: [email protected] >> >> >>> For additional commands, e-mail: [email protected] >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: [email protected] >> >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Olivier Lamy >> >> > http://twitter.com/olamy | http://www.linkedin.com/in/olamy >> >> > >> >> > >> >> >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> > >> >> > >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
