guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hygienic rewrite of (ice-9 expect)


From: Daniel Dinnyes
Subject: Re: Hygienic rewrite of (ice-9 expect)
Date: Mon, 29 May 2023 02:40:21 +0100

Thanks for the reply.

On Sun, 28 May 2023 at 14:39, Maxime Devos <maximedevos@telenet.be> wrote:
I think this would gather more replies if:

  1. It is sent as a patch that can be applied to the Guile source tree.
 
(You wrote:

 > If the community likes this implementation, I would be happy to
 > apply/rebase my changes onto the official repo, and then we can go
 > from there!

but to determine whether I'm happy with it, it would be convenient if
this were a proper patch.)
(I'm not actually reviewing Guile stuff at the moment, but I find it
likely that some others might hold the same view.)


Regarding patches, I think I've read somewhere that GNU wants contributions in some different format,
than just URLs to pull-able GIT repos. Could you share with me some guide how to do such patches,
or what format they are needed?

I am assuming this is the repo of current guile tree, onto which to apply my changes.
Onto which branch?

Would it possible to fork the repo on savannah, and then raise a PR from there instead of patches?
Also, I've tried to create account on savannah, but it keeps getting deleted.
What would you recommend I do to ensure my account doesn't get removed?
 
  2. It is split into two patches: a patch that only does the hygienic
     rewrite, and an additional patch that adds the new features.

     Then people who are interested in the patch for the hygiene but
     don't really grok (or are uninterested in, or don't have time for)
     the new features can ACK or NACK the first patch without having to
     worry about the second patch, and additionally it becomes easier to
     verify there are no new bugs.

No probs, would do so!
 
  3. You respect the LGPLv3.0.  The LGPLv3.0 requires you to follow
     most terms of the GPLv3.0, but you didn't follow 5(a),
     4(a) ‘keep intact all notices’ and 4(a) ‘give all recipients a copy
     of this License’ -- the LPGLv3 is more than only the LICENSE file
     you included; it includes parts of the GPLv3 by reference.

     Also, you only put the LGPLv3.0 text, without specifying a version
     number. Then by ‘6. Revised Versions of this License’ of the LGPL:

 > If the Library as you received it does not specify a version number of
 > the GNU Lesser General Public License, you may choose any version of
 > the GNU Lesser General Public License ever published by the Free
 > Software Foundation.

     you are licensing your implementation as LGPLv2.0+, but
     that's illegal, because your implementation is a rewrite of Guile's
     and hence most likely a derivative work of Guile 3.0, and
     Guile 3.0 is LGPLv3+ licensed, not LGPLv2+.


I didn't notice that I've added LGPL licence instead of GPL! If you look at my other code which uses this module,
those are all GPLv3. It could be that I've realised that Guile itself is under LGPL? Not sure, I can't recall it!
Nevertheless, this licence itself is LGPLv3, not v2!

I am not sure I would agree with your assessment about illegality, and the derivative work categorization.
Even though these macros happen to expand to something similar as the original ice-9 implementation,
the code itself is quite significantly different! If this is to be used in ice-9, it would have to completely
replace the original expect.scm file, as nothing was copy/pasted from there. The fact that parameter binding
names are the same is necessary for backwards compatibility, so those wouldn't count even under the US laws.

On second thought, I am wrong! The expect-select helper function looks like a direct copy-paste job... little naughty me!

Nevertheless, I would be happy to add the necessary notices if that is required.
Also, IIRC there would be another copyright assignment administrative work
somewhere down the line?

Best regards,
Daniel
 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]