fortunately i am learned
a clear analogue of your hypothetical is: fantasy swords and their nomenclature. describing a sword and reference common knowledge about decorative elements, materials, geoemtry and fabrication copyright applies to literal text of a creative work. and oracle v google makes this interp sound for software. building dimilar code for a similar task in a different language is definitely not infringing unless its also copying all the text from the source application like some sort of text rpg. in technical domains, the word compiler means compiler and its used in more than one project without issue. i really want to know what other prjects have zonking, knot typing , the same coding styke etc. its a genuinely complex idiosyncratic code base! and no auto regressive model will write and valdiate a plausible patch without reading / loading dome files, which by the power of autoregression will look like ghc flavored haskell. can someone actually try to manufacture a synthetic instance of a llm trace that verbatime copies gpl code from dome other haskell project? i cant see thst sneaking in given auto regression and haskell corpus. itd be very interesting to be incorrect, and it would help ground this dialogue. cauee its easier to prove an exists rather than forall On Tue, Sep 1, 2026 at 12:33 PM <[email protected]> wrote: > You seem to assume that cross-language copyright infringement is > impossible and > that copyright infringement must involve either very local things like > naming > conventions or global things like architecture. > > I am not learned in software IP law, but the above assumptions seem > plainly > false from the little I do know. > > It could just be a few functions from another project, possibly in a > different > programming language, adapted to Haskell and the GHC naming conventions. > Also, > there are plenty of compilers or just general libraries written in Haskell > which contain code that could also be used in GHC. > > The fact that there is little comparable code in the training set could > also > mean the LLM is more likely to copy a significant part of a single project > as > there is less code to “learn” from. > > Cheers, Jaro > > On 9/1/26 17:26, Carter Schonwald via ghc-devs 'ghc-devs at haskell.org' > wrote: > > this copyright thread confuses me, because …. what Haskell code thats > public > > could these model echo into a ghc edit that isnt gonna be basically ghc > code? > > the architecture and naming conventions and code style is quite > distinct and > > theres very few salient hs code bases that would actually be salient, > and > > translating an algorithm or data structure from one programming language > does > > not create copyright risk wrt the translated code except to the extent > string > > literals or specific data is copyrighted… > > > > i would love examples that ground the ip risk with > > > > now if we were talking abiut a bsd open source nosql db or web server, > there’s > > would be lots to worry about agpl / gpl/ that commercial one that > converts to > > apache after k years. in the case of ghc the very style and architecture > just > > creates a risk of a model generating old no longer correct ancient ghc / > > haskell code! > > > > caveats: my family is basically all software ip lawyers and ive had to > navigate > > quite complex ip nuances in my work over time. > > > > On Sun, Aug 23, 2026 at 2:34 AM andrew.lelechenko--- via ghc-devs <ghc- > > [email protected] <mailto:[email protected]>> wrote: > > > > Hi Tom, > > > > > don't these two adjacent sentences contradict one another? > > > > I don't see how. Is there "an immediate or visible danger"? No. Is > there a > > way to eliminate any potential danger around LLM usage? No, "until > the > > matter is actually tested by courts". Is it worth to spend five > digits on > > some sort of "middle way", which might alleviate but not mitigate a > > potential but unspecified danger? Also no. > > > > Best regards, > > Andrew > > _______________________________________________ > > ghc-devs mailing list -- [email protected] <mailto: > [email protected]> > > To unsubscribe send an email to [email protected] <mailto: > ghc- > > [email protected]> > > > > >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
