savannah-register-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #16238] Submission of Fidei - Take back your faith


From: Florian sp1rit
Subject: [task #16238] Submission of Fidei - Take back your faith
Date: Tue, 6 Sep 2022 16:03:28 -0400 (EDT)

Follow-up Comment #6, task #16238 (project administration):

[comment #5 comment #5:]
> I'm out of context.  AppStream is a free software, isn't it?  Then one can
modify that function to include any strings needed.
> 

Yes, that isn't the issue for myself, but for inclusion in distribution
repositories. The argument is, that because distros will merge various
metainfo files together, "it is not feasible to test every copyleft license
for mutual compatibility and compliance when combining metainfo metadata with
other data into one larger assembly fully automatically" [0] and I guess it
just doesn't work legally with the GPL family of licenses. (the CC-BY-SA seems
to me like a decent copyleft option available; as this isn't source code
anyways)


> > The page you linked doesn't really specify how to handle such a "dual
licensing" case.
> 
> You have to understand what the licenses you use imply and how they combine.
 For more info, you can check the [//www.gnu.org/licenses/gpl-faq.html GPL
FAQ] and the [//www.gnu.org/licenses/license-list.html GNU License List].
> 

The [//www.gnu.org/licenses/license-list.html GNU License List] does list the
CC BY-SA 4.0 as one way compatible with the GPLv3. But that isn't really what
I need. I'd like some kind of resource that tells me how to proceed (license
header wise) in cases where I explicitly licensed files under both the
AGPL-3.0 and CC-BY-SA-4.0.

Would something like what Qt5 is doing be fine? (but obviously with
exclusively free licenses)
```
// Copyright (C) 2020 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR
GPL-2.0-only OR GPL-3.0-only

(--- BEGIN SOURCE ---)
```
as that would also solve the other issue.

> Comments in source code shouldn't affect the size of the executable; if they
do and the size is important, then you should reconsider your building
process.  The developer shouldn't compromise between source code readability
and the efficiency of the translated binary.

yes, but these aren't really source files, but rather resource files. Think of
it like a tar file with a bunch of necessary resources contained within. But
instead of it being a file on the systems filesystem, the contents of the file
are part of the .data section of the binary.


[0]:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?16238>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]