If iuse GPL code result dont need be GPL code? yes this is not AmigaOS or MorphOS or even AROS releated i ask here becouse i am mostly here. i think using few GPL based codes in my projects.

@Vanhapolle

yes it does. There are very few times you wouldn't need to license your code as GPL'd code if you use GPL code. It can be done in linux by only using gpl'd code in plug-in form. However even at that the plugin must run as a separate task.

See Plug-ins

Quote:

If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in? (#GPLAndPlugins) It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way. If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case

Last edited by terminills on 16-Dec-2014 at 12:37 AM.

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@Vanhapolle

GPL is a so-called "viral licence", which means that almost everything that touches GPL code will become GPL as well. You can just adapt a GPL program to act as individual plug-in for other, differently-licensed software but you will have to comply with GPL restrictions about it. Please read all GPL terms paying attention to subjects like 'derivate works' and so on.

Surely you can't embed GPLed code into your non-GPLed programs.

If you're aiming at re-using open source code for your projects, please look for APL, MPL and BSD-like licensed one instead. These licenses are more tolerant and commercial friendly than the GPL, which is mainly driven by politics and ideologies, but it's not a wise choice for practical reasons.

@paolone

Quote:

If you're aiming at re-using open source code for your projects, please look for APL, MPL and BSD-like licensed one instead. These licenses are more tolerant and commercial friendly than the GPL, which is mainly driven by politics and ideologies, but it's not a wise choice for practical reasons.

I'd add LGPL to the list. It's quite common license that's often confused with GPL (well, they ARE related), but allows linking with code that has "GPL-incompatible" license.

There's also MIT, which is a lot less involved than I thought it was. In fact, it's so simple I might formerly licence my stuff under MIT in the future (it's basically what I use anyway with different wording).

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

Finely LibPNG is not GPL i asked who mantains it s fine my uses. now i try solve same for LibJPG,and Maybe LibTIFF. and make basic output modules few other formats.(mainly my needs iFF and "simple BMP",RAW)

@Vanhapolle

libpng libjpg and libtiff are all free

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

yes. now some other formats needs solving i found easy lib for BMP but i dont found contact developer.(is in Google code).

@broadblues

Quote:

broadblues wrote: @Vanhapolle libpng libjpg and libtiff are all free

Free as in GPL, or something actually free?

libpng at least has its own license.

@Vanhapolle

I would stay using shared libraries were possible and avoid link libs.

At least MorphOS contains: png.library, tiff.library, png.library, jfif.library so if you want to stay multiplatform check if they are there and use them.

This reduces memory usage and the libraries get updated by the os developers.

If it comes to MorphOS I would use reggae and on other systems datatypes.library to automagically be able to handle all file formats available at once.

@Jupp3

Free as is free BSD like licenses, even attribution is not compulsory (at least for png and tiff, might be for jpeg)

This is true of most image format licenses, people creating a format want it to be used (there are rare exceptions ofcourse, as always, just read the licnse in the software archive before using).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Jupp3
GPL is more free than other licenses, just as they are more free than the GPL.
Depends on what one wants out of it and who the "one" is.

@megol

Quote:

megol wrote: @Jupp3 GPL is more free than other licenses, just as they are more free than the GPL. Depends on what one wants out of it and who the "one" is.

Well, my main point was, it's pretty useless to talk about "free", unless you also specify which interpretation of it you mean

And instead of free, you could talk about whether or not license spreads by dynamic linking etc. and whether or not it requires source release to begin with (which was the point of this thread)

-EDIT-
As for libpng/tiff/jpg, using reggae / datatypes would be more "native" way, you may lose some control and less often needed options, and I'm not sure how well datatype saving works nowadays (I don't think it worked too well in 3.x times)

Last edited by Jupp3 on 20-Dec-2014 at 01:41 PM.

@Jupp3

Quote:

As for libpng/tiff/jpg, using reggae / datatypes would be more "native" way, you may lose some control and less often needed options, and I'm not sure how well datatype saving works nowadays (I don't think it worked too well in 3.x times)

Some people say the stupidest things. Datatypes is a convenient fallback for image loading but not more "native" than using libpng et al directly.

Datatypes are for programs that simply need to load an image (or other datatype) and they will also handle display if need be to. An image proccessing program (and vanhapolle has been talking in these terms throughout) naturally needs low level access to the file format and per format control over saving. Perhaps you might argue for png.library rather than statically linked libpng but even then one is not more "native" than the other.

Currently sketchblock handles import and export via datatypes, but that has always been a temporary thing. SketchBlock Pro will have loader / saver plugins. (One of which will no doubt be datatypes..)

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

Some people say the stupidest things. Datatypes is a convenient fallback for image loading but not more "native" than using libpng et al directly.

You are correct. MorphOS nowadays comes with png.library etc. so it's definitely officially supported by the OS developers. No idea about OS4 though.

"Native" was perhaps the wrong word here (which is exactly why I wrote it between ""), or maybe not... Think of "native americans" for example. They were there first (like datatypes), before others came.

But yes, like I already said, it's likely more restricted.

And with datatypes, on 3.x at least you probably would need to install ones for needed formats first.

Last edited by Jupp3 on 21-Dec-2014 at 01:33 PM.

LibPNG is thinked here mainly for writing. and maybe someday adding 48bit support etc.

@Jupp3

Quote:

They were there first (like datatypes), before others came.

Datatypes clearly do not precede the lower level image libraries, there would be no jpeg datatype without an earlier libjpeg.a

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

Datatypes clearly do not precede the lower level image libraries, there would be no jpeg datatype without an earlier libjpeg.a

That's true. if we switch the discussion to jpg, that indeed predates first public datatypes release by 1 year or-so. If we stay with png, that came few years later.

But yeah, you're correct in what you are hinting at - png datatype is likely based on libpng (and same for libjpeg, if we switch topic), and no-one was using png with or without datatypes, before libpng was released.

Which is actually a really good reason to support datatypes. All "datatype-aware" programs written before png standard was out should load png (and any potential future formats) just fine, as long as suitable datatype is installed later.

But yes, in this case libpng definitely makes more sense. I think I have some libpng load & save code around somewhere (and also datatype loader)

@Jupp3

You dont need libpng. You can load PNG images using zlib and some glue code.

Since PNG support on real Amiga is quite unpredictable i.e. missing or broken png.datatype I wrote own PNG loader to use on some projects.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

We can switch topic. One reason why i think use LibPNG (for example) saving images is Datatypes saving is not mabe work all fileformats,and is dont need speffic platform but maybe mos i can look these libs but i dont know how much when i maybe want do mostly code which works all amiga type platforms. But i dont yet know anything but i must continue my tests soon. and when i get "base" working i can do more features.