I'm sorry I've sent message to FSF to get some feed back because could be or not a license issue if you copy the code but adapt it to Vala conventions, is it an original work or derived one?
El ago 15, 2013 3:16 p.m., "Simon Kågedal Reimer" <skagedal gmail com> escribió:
>
> Hi Daniel,
>
> I don't think this question of licensing belongs on vala-list since it
> really is unrelated to Vala, but briefly: no, we can't remove or
> change a license on someone else's copyrighted code unless explictly
> allowed in the license, which is not the case with MIT/X11, but it is
> compatible with (and less restrictive than) GPL/LGPL so such code can
> easily be included with an otherwise LGPL:ed library. I don't think
> this is an issue. Anyway, no code is written/ported yet :)
Your right. But any way just asking to FSF.
>
> While we have vala-list's attention, I'd be curious to hear if anyone
> knows of any succesful ports of C# to Vala. Are there maybe even some
> kind of tool out there that aids with boring, automatable tasks such
> as naming conventions..?
>
This question was asked before, and because no such tool exists jet, and requires hand made changes, like to use GLib for most operations I think.
> Regards, Simon
>
> On Thu, Aug 15, 2013 at 7:04 PM, Daniel Espinosa <esodan gmail com> wrote:
> > This is a question to relicense re-written or ported code from Mono Project
> > source in C# to Vala.
> >
> > Is it possible to copy that code port it to Vala and release it using LGPL?
> >
> > Vala [1] is very similar to C#, but relays on GObject and translate to C.
> >
> > El ago 15, 2013 6:18 a.m., "Simon Kågedal Reimer" <skagedal gmail com>
> > escribió:
> >
> > On Tue, Aug 13, 2013 at 5:58 PM, Daniel Espinosa <esodan gmail com> wrote:
> >>
> >> Don't worry all here are volunteers. I would like to see your work in a
> >> branch of GXml, it almost compile in master (if not please tell me and can
> >> fix it for you).
> >
> > Ok, I hope to have a go at this during the weekend. It does make
> > sense, as you say, to do this earlier rather than later. There is only
> > really one overlapping type, the enum GXml.NodeType [1] vs.
> > Acme.XmlNodeType [2].
> >
> > A note on a comment in [1]:
> >
> > // TODO: want a method to convert NodeType to a string
> >
> > Vala provides this automatically! For example,
> > GXml.NodeType.ATTRIBUTE.to_string () will give "ATTRIBUTE". If one
> > wants a nicer representation, perhaps "Attribute" instead, one can
> > manually override to_string(); see this blog post: [3]
> >
> > I've also used this technique in Acme.XmlNodeType for a method that
> > checks if a node of type X can be a parent of a node of type Y, useful
> > for sanity assertions. I assume that the same rules apply in the DOM
> > as when reading?!
> >
> > I think that the values for this enum should be explicitly given, as
> > they have to correspond with the same values in libxml2. This also
> > makes the Vala bug mentioned in a comment in [1] not relevant.
> >
> > [3]
> > http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html
> >
> >>> I've also considered not using libxml2 for at least some parts. The
> >>> XmlWriter would not be too difficult to rewrite in Vala. This would
> >>> make things a little more manageable. I've also peeked in the Mono
> >>> sources, they have an implementation of this that one could try
> >>> porting from C# to Vala.
> >>>
> >>
> >> This is a great idea! Just we need to check license issues.
> >
> > The license shouldn't be a problem, the Mono classes are released
> > under the MIT license. What could conceivably be a problem is the
> > scare of Microsoft patents. The core XmlReader/XmlWriter stuff is part
> > of the ECMA-335 [4] standard, so that isn't a problem, but Mono also
> > implements additions from Microsofts .NET classes. I don't think this
> > is a problem either, but others might disagree.
> >
> >> Richard have the idea to rewrite libxml in Vala any way, may be most of
> >> your
> >> work will be reused by DOM.
> >>
> >> I think use Xml.TextReader behind is really good to parse XML documents.
> >
> > Yes, I agree it makes sense to have Xml.TextReader as the core parsing
> > module. This is also what Mono/.NET does. libxml2 is kind of the other
> > way around, the TextReader built on top of SAX and DOM. For efficiency
> > it could be beneficial to reimplement/port TextReader as a straight
> > forward-only non-caching pull parser. However, it would be unwise to
> > prematurely throw out libxml2 since it provides lots of useful
> > features, DTD validation, XML Schema validation, RELAX-NG
> > validation.... etc. There's an impressive effort behind it, even if
> > the API and documentation is a bit messy.
> >
> > One idea would be to have XmlReader as a proxy class that uses
> > different implementation classes under the hood. If no validation or
> > other other features are requested, we could use our own parser. If
> > needed, we use libxml2 (but hide it's complexity, i.e. we don't let
> > the user specify all kinds of parser options that libxml2 exposes).
> > (We wouldn't use our own parser unless/until it provably has benefits,
> > such as performance or features that might be hard to implement using
> > libxml2 such as an async TextReader.) But this is just thoughts on
> > possible directions in the future.
> >
> > Of great importance here is of course conformance testing. I've begun
> > work on testing Acme.XmlReader/XmlWriter with W3C's XML Test Suite
> > [5].
> >
> >> Just Richard have created. These are the firsts messages.
> >>
> >> And need to suscribe I think.
> >
> > Ah, I had subscribed, just missed the "confirmation needed" mail. :)
> > Now I'm properly subscribed.
> >
> > Regards, Simon
> >
> > [1] https://git.gnome.org/browse/gxml/tree/gxml/NodeType.vala
> > [2]
> > https://gitorious.org/fido/acme-xml/blobs/master/acme-xml/acme-xmlnodetype.vala
> > [3]
> > http://blog.yorba.org/jim/2011/05/a-few-of-my-favorite-vala-things-enums.html
> > [4] http://www.ecma-international.org/publications/standards/Ecma-335.htm
> > [5] http://www.w3.org/XML/Test/