The counterargument is that if they want to be able to lock down their code while getting the benefits of free software, developers should be able to prevent that. (L)GPL provides a mechanism.
No one is forcing the code to be used. Make your own implementation, or if the code is important enough to use, accept its license. It's free with conditions, if the conditions aren't acceptable, don't take the gift ;) On Wed, Mar 2, 2016 at 2:00 AM, John B <[email protected]> wrote: > Hello, thank you for your email. I didn't want to get into too many > details since most people are familiar with the license differences. > However, I am not concerned about to the code that links against it. I am > talking about modifying tinycc and linking against a derivative, > essentially that becoming my code. Here is a fact of life: businesses and > people who want to build a product to sell, they can take out all of the > copyright protections and licenses and hire the best lawyers all they > want. But that pales in comparison to the low low price and effort of > just keeping everything a trade secret. lgpl is the opposite of that. In > some cases people may not even necessarily want to disclose the use of 3rd > party code. People keep secrets when they write proprietary software and > if that means utilizing an inferior yet more license compatible library, so > be it. I am not too sure if my business partner and I care about > disclosing, but providing source for a derivative is simply non-viable. > And of course I would want to build a derivative. > > > Hope this helps clarify! Sorry if the formatting of the email is bad, I > am using outlook.com and it inserts way too many new lines. > > Regards, > John. > > ------------------------------ > *From:* [email protected] > <[email protected]> on behalf of Nids < > [email protected]> > *Sent:* Tuesday, March 1, 2016 11:01 PM > *To:* [email protected] > *Subject:* Re: [Tinycc-devel] License is too restrictive for real-world > use. > > Ehm... No. > > The LGPL just states that when you redistribute your product, the code of > TinyCC, or its modified version, must be redistributed/made available. The > same does NOT apply to the code that links against it. > > What you are describing is the GPL license and not the LGPL one. > > I could be wrong, can you please point me to the part of the license > stating what you are saying? > > Typed on a very small keyboard... > ------------------------------ > From: John B <[email protected]> > Sent: 02/03/2016 06:07 > To: [email protected] > Subject: [Tinycc-devel] License is too restrictive for real-world use. > > Hi, > > > I really love playing around with tinycc for jit-enabled scripting. There > are so many applications to this and by far tinycc is the single-most best > tool for the job that I have so far evaluated. > > > If you evaluate luajit or llvm etc., they can execute code as fast as > tinycc. They can call extern C functions just as fast as tinycc. But > there is one important criteria for flexible jit scripting that only tinycc > can do. No other jit library seems to be able to do this one simple task: > Repeatedly call into the compiled script from C in a very tight loop. So > your application can define a script and execute it in tinycc or luajit or > whatever... and each of these can call into your main application (pull) > very fast. TinyCC is about the only ultra fast jit in existence that can > do reverse push calling. So once you have the compiled object loaded with > the function pointer returned, you can call it as many times as you want > without worrying about performance. It's beautiful, it's useful, it's... > under lgpl. It's off-limits. > > > This is important... it let's you build compiled expressions. You don't > really need a jit scripting engine for fully fledged procedures or > algorithms. I mean you can, but to me it is all about compiled > expressions. Almost like say you are building a regex parser. If you do > that in other jit implementations, be prepared for your script to pull all > of the text down otherwise you are going to have a bad time. TinyCC on the > other hand, you can parse it wherever you want and just send portions to > the compiled expression. TinyCC could own the jit scripting market right > now. > > > It falls down and becomes completely unusable, all because of it's > license. Lgpl is this magical property that turns anything it touches into > a toy. I am not independently rich, and I work hard in the hope I can sell > my software. That is just the how it is for me. LPGL prevents me from > ever touching TinyCC in my code. And it is a darn shame, because it is > exactly the library I want to use for scripting and i'll use it in very > imaginative ways. I don't want to use LuaJit, but the license tells me > otherwise. Luajit is a wonderful tool but it has it's own problems that > tinycc doesn't have. > > > Please, if you want to consider tinycc being more relevant than it is, and > being adopted in big ways so that people can build push calls instead of > pull scripts, it just hinges on dropping the toxic lgpl and switching to > e.g. bsd. There are so many things I want to do with tinycc but that is > not why I want to be a developer. Not until I win the lottery, anyway. > > > Thank you for taking the time to read if you did [image: 😊] > > > Regards, > > John. > > > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > -- -Austin
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
