Wrote

I don't want to be a spoilsport but I think it was GPL licensed.

For me it is not so important. If I convert the code from Java to C# then it will be something similar to Jasymca but not Jasymca. So I can use my code as I want.

Intellectual work of thousands of programmers who have worked in the past era, should be the province of all mankind in any way and not under GPL license. The same applies to engineers and scientists.

At this rate, soon someone by changing the pair of genes will lay claim to human DNA (under GPL license).

P.S. And if you are born under license, then the body will have a record: licensed and authorized for personal use only. Reproduce prohibited.

Dear Slava, thanks for the rant.
Actually I don't care much either because of my ideology, G-Marxism.
No..seriously, the problem is that many of these libraries are built upon works licensed under GPL and so on.
I understand that this license aims to courage/discourage programmers to share/close their code in a expansive/reduced way.
As you say, it is arguable that at certain point someone decides to license something based on the work of many others.
Anyway, I think that SMath does not necessarily contradict the idea of this kind of 'don't break the chain of open code' license as it is basically a freeware program whose advantage ove others is its stable and attractive user interface but also the fact that is freeware.

I'd like to mention a number of libraries that might be of interest:
OpenAxiom
FriCAS
REDUCE
JAS
symja

More libraries to consider:
OpenScience > Mathematics
Mathmatics, Physics, Plotting

BTW, what about Jython to manage the python libraries from the above posts and make a .dll out of a .jar with ikvm

Edit:

This approach of converting java libraries to .NET assemblies by means of the tool ikvm is interesting. For example these are some java libraries that would be nice to use embedded in SMath : JFreeChart ; JQuantity

Ok, I will keep in mind.

All these license scruples are more to avoid any objection against distributing your work
Thanks again for your great plugins.

Hi, I've updated this post
http://en.smath.info/forum/yaf_postsm9943_Gnuplot-plugin.aspx#post9943
with some more resources, a symbolic engine: 'Reduce',
and two java libraries: a nice library for plotting (JFreeChart) ; a library for math precision (JQuantity).

I'm really intrigued about the posibilities of this magic tool, ikvm, to port java to .net dlls.

Could anyone shed some light about using GPL to make opensource plugins for a proprietary software ?
I'm afraid that I've been talking too much about this matter despite not being a lawyer.
There does not seem to be any issue according to this article, please read the paragraph where it says "mix proprietary and GPLed software" and draw your own conclusions.
These other articles were the cause of my objections to take advantage of GPL code:
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
http://stackoverflow.com/questions/141605/is-it-legal-way-to-get-use-gpl-code-in-close-source-application-through-plugin
All these arguments are questionable but now I think that the spirit of the SMath project is above any legal issues since the program is a freeware alternative to other expensive applications, following the idea of taking and giving back, besides such plugins could be distributed free of charge by the community users along with their source code.
I feel like my days of suggesting resources to make plugins are coming to an end. :d

There's no problem to use GPL software to make plugins here.

First off, the plugin is a separate software, and need not use a compatible license with the main software (I mean SMath in this case). A problem could only arise if either SMath license or GPL explicitly put restrictions to license of plugin/main software; but it is not the case. As a more general case, you may consider just any program to be a kind of "plugin" to an operating system; you see that there are no problems using GPL software on proprietary licensed Windows machines

Two distinct cases should be considered:
1. A GPL'ed code is used inside the plugin code (say, GPL'ed .lib )
2. The plugin is used as a "wrapper" to communicate between SMath and (possibly unmodified) GPL'ed software.

In the first case, the "virus" nature of GPL makes it obligatory to license all the plugin (its DLL and source code) under GPL terms. But this only covers the DLL (compiled code) and its sources; no impact on SMath itself, as the plugin DLL does not embed itself into SMath code.

In the second case, the plugin may be licensed as author wishes. The code isn't derived from the GPL'ed software; the only restriction here is that if the plugin is distributed with the GPL'ed software modules included, then the plugin package must contain the corresponding license for that software (this holds true for almost any software that you include into your package) and a reference to a place where the source code for the GPL'ed software may be obtained.

Some ignorant GPL lovers used to demand that any work made using a GPL tool to be licensed under GPL terms; thus, if you use, say, gcc, then you have to use GPL for your code. On these grounds, you could imagine that if you used emacs for education, then every your work that is based on the knowledge taken from the education must be GPL'ed! But the FSF itself denied this bold interpretation; this is just a nonsense.

I'm glad that you see this matter so clear, that may explain why some programs have parts of them with different license.
Then there are more .NET resources available for SMath than I had ruled out. It is even possible to port java libraries and code plugins in java by means of the .Net/Mono tool mentioned above in this thread.

It seems that ikvm has problems with jfreechart,
this is another opensource project that aims to port jfreechart to.net2
J by J#

Edit:

If you download the demo, you can find some dlls like a JFreeChart.dll
well this another alternative for your consideration, there are already a few in this forum

Edit:

video showing the JFreeChart.NET demo
This project uses J# from MS so I don't know if it works in Linux, also 64bit compatibility should be checked.

Just to don't forget this

With the new skills of uni on languages handling, there are more chances to see this plugin?

We can get both gnuplot and matplotlib
As for the matplotlib the size of plugin will be around 30 MB in zip and 70 MB on disk. Is this normal for you?
About the plugin interface. I think it will be something like Script region.