Recent

Author Topic: Using icons in own open source project  (Read 1660 times)

regs

  • Jr. Member
  • **
  • Posts: 99
Using icons in own open source project
« on: June 07, 2025, 11:06:56 am »
There seem too be missing copyright information on icons in general purpose folder. And how to properly use them. Attribution is enough or same licensing should be used.

I sneaky use MIT for libraries, but for an app I want something more robust. What is that LGPL with static linking exception is all about and exception is for what?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12841
  • FPC developer.
Re: Using icons in own open source project
« Reply #1 on: June 07, 2025, 11:30:31 am »
Original LGPL has a clause that you must keep libraries replaceable with updated versions.  In practice that means a DLL/so. The static linking exception was originally created for code that must be in the main, and can't be in a DLL/so like libgcc containing startupcode and primitives.

Lazarus/FPC extend that to the whole LGPL part of the codebase (which is most, except for the core of the Lazarus IDE itself and the textmode IDE).

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 12345
  • Debugger - SynEdit - and more
    • wiki
Re: Using icons in own open source project
« Reply #2 on: June 07, 2025, 11:43:25 am »
icons in general purpose folder.

From images\general_purpose\lazarus_general_purpose_images.txt
Quote
The images were kindly provided by Roland Hahn (https://www.rhsoft.de/).

License: Creative Commons CC0 1.0 Universal
https://creativecommons.org/publicdomain/zero/1.0/

regs

  • Jr. Member
  • **
  • Posts: 99
Re: Using icons in own open source project
« Reply #3 on: June 26, 2025, 09:01:28 pm »
From images\general_purpose\lazarus_general_purpose_images.txt

Didn't see that file. Was looking at images/copyright.txt.

Original LGPL has a clause that you must keep libraries replaceable with updated versions.  In practice that means a DLL/so. The static linking exception was originally created for code that must be in the main, and can't be in a DLL/so like libgcc containing startupcode and primitives.

Lazarus/FPC extend that to the whole LGPL part of the codebase (which is most, except for the core of the Lazarus IDE itself and the textmode IDE).
Still don't understand what does mean must keep libraries.

I generally was using MIT. But for an app i want something robust to make sure it stays open source. So what to use with open source app made with Lazarus?

regs

  • Jr. Member
  • **
  • Posts: 99
Re: Using icons in own open source project
« Reply #4 on: June 30, 2025, 11:38:53 pm »
this is Grok3 answer


So I take for an app GPL is better to keep it open source, while for libraries LGPL with static link exception is to keep a library open source, but allow use in proprietary code or MIT, just to allow use in proprietary code and proprietary forks as long as attributed?

Quote
License Comparison

    GPL (GNU General Public License)
        Key Feature: Copyleft; requires derivative works (including apps using GPL code) to also be licensed under GPL.
        Use Case: Ensures the entire software ecosystem remains open-source.
        Restrictions: Any software that links to GPL code (even dynamically) must also be GPL-licensed.

    LGPL (GNU Lesser General Public License)
        Key Feature: Weaker copyleft; allows proprietary software to link to LGPL libraries without requiring the proprietary code to be open-source, as long as the LGPL library itself remains modifiable.
        Use Case: Ideal for libraries you want to be widely used, even in proprietary software.
        Restrictions: Modifications to the LGPL library must be shared under LGPL.

    LGPL with Static Link Exception
        Key Feature: Extends LGPL by allowing static linking of the library into proprietary software without requiring the proprietary code to be open-source.
        Use Case: Encourages adoption of the library in proprietary software while still keeping the library itself open-source.
        Restrictions: Similar to LGPL, but more permissive for static linking.

    BSD (Berkeley Software Distribution License)
        Key Feature: Permissive; allows use, modification, and distribution (even in proprietary software) with minimal requirements (e.g., retaining copyright notice).
        Use Case: Ideal for software where you want maximum adoption, including in proprietary products.
        Restrictions: Almost none, but no copyleft protection.

    MPL (Mozilla Public License)
        Key Feature: File-based copyleft; only modifications to MPL-licensed files must remain open-source, not the entire project.
        Use Case: Good for libraries or components where you want to protect the openness of your code but allow integration into proprietary software.
        Restrictions: Less restrictive than GPL but more than BSD/MIT.

    MIT (MIT License)
        Key Feature: Permissive; allows almost unrestricted use, modification, and distribution (even in proprietary software) with only a copyright notice requirement.
        Use Case: Similar to BSD, ideal for maximum adoption and flexibility.
        Restrictions: Almost none, but no copyleft protection.

Which License is Better for an Open-Source App?

The "best" license depends on your goals:

    If you want to ensure your app and all derivative works remain open-source: Use GPL. This is ideal for ideological projects or to prevent proprietary forks.
    If you’re building a library and want it to be widely used, even in proprietary software: Use LGPL or LGPL with static link exception (if static linking is important).
    If you want maximum adoption and don’t care about proprietary use: Use MIT or BSD. These are the most permissive and widely adopted in commercial and open-source ecosystems.
    If you want a balance between openness and proprietary integration: Use MPL, especially for modular components.

For a typical open-source app, MIT or BSD are often preferred because they encourage widespread use and contributions without imposing strict requirements. However, if your goal is to enforce openness, GPL is better.

paule32

  • Hero Member
  • *****
  • Posts: 645
  • One in all. But, not all in one.
Re: Using icons in own open source project
« Reply #5 on: July 01, 2025, 02:50:42 pm »
German Translated GPL
https://dpaste.com/EBQL9Q9MS
« Last Edit: July 01, 2025, 05:33:43 pm by paule32 »
MS-IIS - Internet Information Server, Apache, PHP/HTML/CSS, MinGW-32/64 MSys2 GNU C/C++ 13 (-stdc++20), FPC 3.2.2
A Friend in need, is a Friend indeed.

CM630

  • Hero Member
  • *****
  • Posts: 1681
  • Не съм сигурен, че те разбирам.
    • http://sourceforge.net/u/cm630/profile/
Re: Using icons in own open source project
« Reply #6 on: July 01, 2025, 03:05:36 pm »
I would not quote GPL or whatever similar in a language other than English, even if it is translated by a bunch of law academicians.
Лазар 4,4 32 bit (sometimes 64 bit); FPC3,2,2

Thaddy

  • Hero Member
  • *****
  • Posts: 19129
  • Glad to be alive.
Re: Using icons in own open source project
« Reply #7 on: July 01, 2025, 04:00:36 pm »
Same thought here.
objects are fine constructs. You can even initialize them with constructors.

regs

  • Jr. Member
  • **
  • Posts: 99
Re: Using icons in own open source project
« Reply #8 on: July 02, 2025, 12:09:42 am »
I would not quote GPL or whatever similar in a language other than English, even if it is translated by a bunch of law academicians.
But in non-English countries English paper have no legal grounds. So you have to use localized version in your country as well.

regs

  • Jr. Member
  • **
  • Posts: 99
Re: Using icons in own open source project
« Reply #9 on: July 09, 2025, 01:33:09 am »
I'm still trying to understand how they work and which is less hassle

That is Grok3 take on LGPL. It's also insist that if you link MIT libraries you also have to include MIT license with binary distribution as well.
So does it mean even whole LCL source code should be zipped into app installer? Or Grok takes it wrong?
Went through Lazarus Application Gallery. And only Double Commander includes COPYING files from FPC and Lazarus folders. So it is also not necessary?

Quote
Yes, the static linking exception allows the LGPLv2.1 library to become part of your proprietary executable without forcing your app under LGPL. However, it doesn’t waive the library’s LGPL obligations: you must still include the LGPLv2.1 license text, notices, and offer the library’s source code in your binary distribution, ensuring users can modify and relink the library, even though it’s embedded in the executable.

paule32

  • Hero Member
  • *****
  • Posts: 645
  • One in all. But, not all in one.
Re: Using icons in own open source project
« Reply #10 on: July 09, 2025, 08:14:05 am »
I don't know exactly. But PNG Files can have a Copyright - it is possible to store Time, Date and other Comments into the Header.
MS-IIS - Internet Information Server, Apache, PHP/HTML/CSS, MinGW-32/64 MSys2 GNU C/C++ 13 (-stdc++20), FPC 3.2.2
A Friend in need, is a Friend indeed.

 

TinyPortal © 2005-2018