Lets get a list of the cases we want to copy. keep the list in the wiki page, and when we have the full list we will review.
On 13 June 2011 14:45, Benson Margulies <[email protected]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
