Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=708765 --- Comment #39 from Mario Sanchez Prada <msanchez@xxxxxxxxxx> 2011-06-03 13:26:22 EDT --- (In reply to comment #38) > (In reply to comment #35) > > Here I disagree, LGPLv3 licensed code can be used as if it was licensed under > > the GPLv3, so no compatibility issues as far as I know, and if external > > contributions are made to this code, relicensing from GPLv3 to LGPLv3 will be > > annoying (ie need to contribute everyone to get their agreement). So I don't > > really see a compelling reason to do the relicensing. > > > Of course it's possible to keep the separate license but then you have to > explain why an integral part of frogr not intended to be used externally needs > its own license. If everything goes into an application licensed under GPLv3, > why do you need LGPLv3 code in a separate directory? This just looks like a > project bundled with the tarball. But that's only my humble opinion. Let's FPC > have a look at this. Mario B. would you ask for a bundled library exception? Yeah, I understand. That's why I added a "Note: <explanation>" in the README file, because the truth is that I hope at some poing to have some time to devote to make it a library (or that someone else step in and do it :-)). Thinking that way, it makes a lot of sense to me to license those files as LGPL. > (In reply to comment #36) > > Ok, it's obvious then (as per your comment and Christophe's) that I > > misunderstood you in the first comments: I though having a .a file was actually an issue > > No, sorry for the confusion. Linking object files directly or putting them in a > static library and link the .a file doesn't make a big difference. Ok, got it. I'll probably get it back to the original situation at some point then. > The question is: Do we have a library that could be used outside the project (and is > promoted a s such) or is it just a module exclusively related to the main > project. After recent events, I'd say now the answer is simple: no, we do not have such a library that could be used outside the project yet. What I'll probably do in the future, unless someone else do it first, is to wait till frogr being stable and feature complete enough so I can forget about releasing new versions for some time, then focusing on starting my "evil plan": 1. Take the flicksoup files out of frogr and release them as an independent library. 2. Try to convince people out there to package that library, so I can further safely make frogr depend on it for future releases, (at least in those distros already packaging frogr). 3. Make the next release of frogr depend on that library, removing all the files under src/flicksoup 4. Release new version frogr depending on flicksoup, finally. How does it sound? Keep in mind that my "evil plan" could take months to materialize, perhaps when my second child is born (late August 2011) it could be a good moment to think about it. Why? well, if you think that I started frogr right when my first son was born, you could understand it would make sense to me to do something similar with flicksoup when the second one comes to life... kind of my "personal way of welcoming my sons to the world of FS", right since their most early days" :-) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review