Moreover, contributing back some changes/enhancements to a library that you use
can mean that you get maintenance of that code for free from the community,
apart from a little initial cost that you would have paid anyway.
Typed on a very small keyboard...
-----Original Message-----
From: "Austin English" <[email protected]>
Sent: 02/03/2016 08:26
To: "[email protected]" <[email protected]>
Subject: Re: [Tinycc-devel] License is too restrictive for real-world use.
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
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
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
