GPL3, copyright, file headers, and naming conventions
77 views
Skip to first unread message
Mestre Lion
May 13, 2012, 1:40:53 AM5/13/12
to endgame-sin...@googlegroups.com
I had briefly talked to Phil about this, but given the (possible) broad consequences, I think it's better to post here for all devs opinion:
i18n was a huge branch that changed almost all files. When adding the finishing touches, I stumbled across several issues:
- All file headers (with the GPL2 preamble) are outdated. The FSF address has since changed from "59 Temple Place, Suite 330, Boston, MA 02111-1307 USA" to "51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA". And to prevent this hassle from happening again, FSF wisely changed this in its GPL3 preamble to: "If not, see <http://www.gnu.org/licenses/>". I fixed this issue only for singularity.py, code/singularity.py and code/g.py (and README.txt), using the url version, as i think a mass-replace deserves a commit of its own, and a broader discussion.
- As for copyright, several years are listed (usually 2005, 2006, 2007, 2008, 2009). This poses a problem: should we also add 2012? Should we edit all files every year? To prevent this, after a /lot/ of research on the legal aspects, I changed those 4 files to 2005 /only/, as for copyright laws only the /first release/ is necessary. This prevents a lot of noise when editing files in the future, keeping patches small.
- What about copyright holders? Current scenario is: Ems and Phil and in all files, Brian and FM in most, I've added myself only to the 4 above, and a there are also a few authors credited individually /in copyright/ in some individual files (but not in README and/or AUTHORS. Shouldn't they?). So, what is the criteria? If a contributor patches a single file, with substantial changes, should he add him/her self to that file? Should copyright notice be uniform for all files (only ems and phil for example), and other credits to README/AUTHORS ? What about extensive/project-wise changes (brian, fm, and myself). Do we waive copyright for individual files, or be included in all of them, (for uniformity's sake), even for files we didn't touch at all? And where to draw the line between "some files changed" and "extensive, project-wise changes"? Singularity, being in Git and GitHub, will soon experience a boom in developers and contributors (at least we hope so), so the project needs a policy regarding this.
- About license: how about switching to GPL3+? I don't want to sound like an FSF fanboy/zealot, but v3 does offer substantial improvements over v2. Take a look here: http://www.gnu.org/licenses/quick-guide-gplv3.html and also here: http://www.gnu.org/licenses/rms-why-gplv3.html . I think that being a game, specially a simple one,Tivolization is a real threat: consider the many embedded devices and handhelds that offer dozens of simple games, usually S/NES-like, with an embedded MAME emulator. So, anyway, if we may end up doing a mass replace to fix the problems above, then going from 2+ to 3+ has zero-cost (in terms of patch size)
- GLP3 again: .. it also does not require any effort: E:S is already (wisely) GPL2 /or later/. So, legally, we don't even /need/ anyone's authorization to re-license it as GPL3+. Of course I would never do anything without ems's and phil's bless, but at least we don't have to hunt down everyone mentioned in all files (trust me, it's a /lot/ of people) to do the switch.
Tough issues apart, now to the easy ones:
- Why the file is called "GPL.txt" ? Standard name (by Debian/Fedora policy, and basically all FOSS projects) is LICENSE (or COPYING). It is also license-agnostic. And, please, let's drop the ".txt". If that was meant to make Windows users happy, it is pointless: file uses Unix line delimiters (\n) instead of Windows CR+LF. So it will look /bad/ in Notepad anyway, regardless of the ".txt"
- Same rationale for README.txt. Windows users cannot double-click in notepad (ok, they can, but it will look crappy), and Linux users are certainly annoyed by the non-standard name. It's README only, period. (I mean, no period :P)
So, let the flame war begins! :D
ML
i18n was a huge branch that changed almost all files. When adding the finishing touches, I stumbled across several issues:
- All file headers (with the GPL2 preamble) are outdated. The FSF address has since changed from "59 Temple Place, Suite 330, Boston, MA 02111-1307 USA" to "51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA". And to prevent this hassle from happening again, FSF wisely changed this in its GPL3 preamble to: "If not, see <http://www.gnu.org/licenses/>". I fixed this issue only for singularity.py, code/singularity.py and code/g.py (and README.txt), using the url version, as i think a mass-replace deserves a commit of its own, and a broader discussion.
- As for copyright, several years are listed (usually 2005, 2006, 2007, 2008, 2009). This poses a problem: should we also add 2012? Should we edit all files every year? To prevent this, after a /lot/ of research on the legal aspects, I changed those 4 files to 2005 /only/, as for copyright laws only the /first release/ is necessary. This prevents a lot of noise when editing files in the future, keeping patches small.
- What about copyright holders? Current scenario is: Ems and Phil and in all files, Brian and FM in most, I've added myself only to the 4 above, and a there are also a few authors credited individually /in copyright/ in some individual files (but not in README and/or AUTHORS. Shouldn't they?). So, what is the criteria? If a contributor patches a single file, with substantial changes, should he add him/her self to that file? Should copyright notice be uniform for all files (only ems and phil for example), and other credits to README/AUTHORS ? What about extensive/project-wise changes (brian, fm, and myself). Do we waive copyright for individual files, or be included in all of them, (for uniformity's sake), even for files we didn't touch at all? And where to draw the line between "some files changed" and "extensive, project-wise changes"? Singularity, being in Git and GitHub, will soon experience a boom in developers and contributors (at least we hope so), so the project needs a policy regarding this.
- About license: how about switching to GPL3+? I don't want to sound like an FSF fanboy/zealot, but v3 does offer substantial improvements over v2. Take a look here: http://www.gnu.org/licenses/quick-guide-gplv3.html and also here: http://www.gnu.org/licenses/rms-why-gplv3.html . I think that being a game, specially a simple one,Tivolization is a real threat: consider the many embedded devices and handhelds that offer dozens of simple games, usually S/NES-like, with an embedded MAME emulator. So, anyway, if we may end up doing a mass replace to fix the problems above, then going from 2+ to 3+ has zero-cost (in terms of patch size)
- GLP3 again: .. it also does not require any effort: E:S is already (wisely) GPL2 /or later/. So, legally, we don't even /need/ anyone's authorization to re-license it as GPL3+. Of course I would never do anything without ems's and phil's bless, but at least we don't have to hunt down everyone mentioned in all files (trust me, it's a /lot/ of people) to do the switch.
Tough issues apart, now to the easy ones:
- Why the file is called "GPL.txt" ? Standard name (by Debian/Fedora policy, and basically all FOSS projects) is LICENSE (or COPYING). It is also license-agnostic. And, please, let's drop the ".txt". If that was meant to make Windows users happy, it is pointless: file uses Unix line delimiters (\n) instead of Windows CR+LF. So it will look /bad/ in Notepad anyway, regardless of the ".txt"
- Same rationale for README.txt. Windows users cannot double-click in notepad (ok, they can, but it will look crappy), and Linux users are certainly annoyed by the non-standard name. It's README only, period. (I mean, no period :P)
So, let the flame war begins! :D
ML
evilmrhenry
May 13, 2012, 11:28:46 AM5/13/12
to endgame-sin...@googlegroups.com
Mestre Lion wrote:
> I had briefly talked to Phil about this, but given the (possible) broad
> consequences, I think it's better to post here for all devs opinion:
>
> i18n was a huge branch that changed almost all files. When adding the
> finishing touches, I stumbled across several issues:
>
> - All file headers (with the GPL2 preamble) are outdated. The FSF
> address has since changed from "59 Temple Place, Suite 330, Boston, MA
> 02111-1307 USA" to "51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA". And to prevent this hassle from happening again, FSF
> wisely changed this in its GPL3 preamble to: "If not, see
> <http://www.gnu.org/licenses/>". I fixed this issue only for
> singularity.py, code/singularity.py and code/g.py (and README.txt),
> using the url version, as i think a mass-replace deserves a commit of
> its own, and a broader discussion.
>
> - As for copyright, several years are listed (usually 2005, 2006, 2007,
> 2008, 2009). This poses a problem: should we also add 2012? Should we
> edit all files every year? To prevent this, after a /lot/ of research on
> the legal aspects, I changed those 4 files to 2005 /only/, as for
> copyright laws only the /first release/ is necessary. This prevents a
> lot of noise when editing files in the future, keeping patches small.
Copyright's like 90 years from the death of the author anyway. Update
> I had briefly talked to Phil about this, but given the (possible) broad
> consequences, I think it's better to post here for all devs opinion:
>
> i18n was a huge branch that changed almost all files. When adding the
> finishing touches, I stumbled across several issues:
>
> - All file headers (with the GPL2 preamble) are outdated. The FSF
> address has since changed from "59 Temple Place, Suite 330, Boston, MA
> 02111-1307 USA" to "51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA". And to prevent this hassle from happening again, FSF
> wisely changed this in its GPL3 preamble to: "If not, see
> <http://www.gnu.org/licenses/>". I fixed this issue only for
> singularity.py, code/singularity.py and code/g.py (and README.txt),
> using the url version, as i think a mass-replace deserves a commit of
> its own, and a broader discussion.
>
> - As for copyright, several years are listed (usually 2005, 2006, 2007,
> 2008, 2009). This poses a problem: should we also add 2012? Should we
> edit all files every year? To prevent this, after a /lot/ of research on
> the legal aspects, I changed those 4 files to 2005 /only/, as for
> copyright laws only the /first release/ is necessary. This prevents a
> lot of noise when editing files in the future, keeping patches small.
the files, or not, it won't matter for the next century or so anyway.
> - What about copyright holders? Current scenario is: Ems and Phil and in
> all files, Brian and FM in most, I've added myself only to the 4 above,
> and a there are also a few authors credited individually /in copyright/
> in some individual files (but not in README and/or AUTHORS. Shouldn't
> they?). So, what is the criteria? If a contributor patches a single
> file, with substantial changes, should he add him/her self to that file?
> Should copyright notice be uniform for all files (only ems and phil for
> example), and other credits to README/AUTHORS ? What about
> extensive/project-wise changes (brian, fm, and myself). Do we waive
> copyright for individual files, or be included in all of them, (for
> uniformity's sake), even for files we didn't touch at all? And where to
> draw the line between "some files changed" and "extensive, project-wise
> changes"? Singularity, being in Git and GitHub, will soon experience a
> boom in developers and contributors (at least we hope so), so the
> project needs a policy regarding this.
larger changes, you can if you want, but we won't force you. I don't see
any reason to define small/large; this is just to keep the number of
copyright holders at a reasonable size.
We might want a CREDITS.txt file, to give a dedicated space to showing
who made what.
>
> - About license: how about switching to GPL3+? I don't want to sound
> like an FSF fanboy/zealot, but v3 does offer substantial improvements
> over v2. Take a look here:
> http://www.gnu.org/licenses/quick-guide-gplv3.html and also here:
> http://www.gnu.org/licenses/rms-why-gplv3.html . I think that being a
> game, specially a simple one,Tivolization is a real threat: consider the
> many embedded devices and handhelds that offer dozens of simple games,
> usually S/NES-like, with an embedded MAME emulator. So, anyway, if we
> may end up doing a mass replace to fix the problems above, then going
> from 2+ to 3+ has zero-cost (in terms of patch size)
>
> - GLP3 again: .. it also does not require any effort: E:S is already
> (wisely) GPL2 /or later/. So, legally, we don't even /need/ anyone's
> authorization to re-license it as GPL3+. Of course I would never do
> anything without ems's and phil's bless, but at least we don't have to
> hunt down everyone mentioned in all files (trust me, it's a /lot/ of
> people) to do the switch.
just a game, and not even multiplayer, so there would be no motive for
preventing changes to a copy, but if you want to upgrade, go ahead.
>
> Tough issues apart, now to the easy ones:
>
> - Why the file is called "GPL.txt" ? Standard name (by Debian/Fedora
> policy, and basically all FOSS projects) is LICENSE (or COPYING). It is
> also license-agnostic. And, please, let's drop the ".txt". If that was
> meant to make Windows users happy, it is pointless: file uses Unix line
> delimiters (\n) instead of Windows CR+LF. So it will look /bad/ in
> Notepad anyway, regardless of the ".txt"
>
> - Same rationale for README.txt. Windows users cannot double-click in
> notepad (ok, they can, but it will look crappy), and Linux users are
> certainly annoyed by the non-standard name. It's README only, period. (I
> mean, no period :P)
easily. Change the eol style to Windows, leave it as .txt
Phil Bordelon
May 13, 2012, 11:51:49 AM5/13/12
to endgame-sin...@googlegroups.com
On 05/13/2012 12:40 AM, Mestre Lion wrote:
> I had briefly talked to Phil about this, but given the (possible) broad
> consequences, I think it's better to post here for all devs opinion:
I was going to post my own analysis, but then EMH posted, and I basically
> I had briefly talked to Phil about this, but given the (possible) broad
> consequences, I think it's better to post here for all devs opinion:
agree with everything e said. So, uh, yeah. Works for me!
P
evilm...@emhsoft.com
Nov 15, 2012, 7:36:02 PM11/15/12
to endgame-sin...@googlegroups.com
After a bit of research, it looks like a main reason for having per-file
copyright headers is to retain copyright when a file gets separated from
the main project. This was said in context of utilities and libraries,
though, where a useful function may be copied, without bringing along the
entire project. For a game, I think this is much less of a potential
concern.
As for assigning copyright, I think that's much less of an issue, and even
if not strictly needed, it's would then be restricted to just one file.
> First off: Sorry for the Necro, but it seems silly to make a new topic.
>
> I've read through MestreLions link and I think the licensing should always
> kept with the times. Therefor I would like to change the LICENSE file
> accordingly.
>
> As for the license headers in each file: Do we really need those? Seems a
> bit excessive. Wouldn't be a single copyright and licensing statement in
> the Readme or something, enough? Lets get rid of all the licensing
> headers!
>
> On a related matter: Is it really necessary for every contributor to note
> down his/her copyright? I mean, we are talking about an GPL project here.
>
> In a nutshell: Update the licensing, get rid of the bulky licensing
> headers
> and put all the copyright information into a central file (AUTHORS
> perhaps,
> or CREDITS, or something).
>
> If I get an OK I would commit these changes. Otherwise: discuss!
>
> Cheers
> Uneron
copyright headers is to retain copyright when a file gets separated from
the main project. This was said in context of utilities and libraries,
though, where a useful function may be copied, without bringing along the
entire project. For a game, I think this is much less of a potential
concern.
As for assigning copyright, I think that's much less of an issue, and even
if not strictly needed, it's would then be restricted to just one file.
> First off: Sorry for the Necro, but it seems silly to make a new topic.
>
> I've read through MestreLions link and I think the licensing should always
> kept with the times. Therefor I would like to change the LICENSE file
> accordingly.
>
> As for the license headers in each file: Do we really need those? Seems a
> bit excessive. Wouldn't be a single copyright and licensing statement in
> the Readme or something, enough? Lets get rid of all the licensing
> headers!
>
> On a related matter: Is it really necessary for every contributor to note
> down his/her copyright? I mean, we are talking about an GPL project here.
>
> In a nutshell: Update the licensing, get rid of the bulky licensing
> headers
> and put all the copyright information into a central file (AUTHORS
> perhaps,
> or CREDITS, or something).
>
> If I get an OK I would commit these changes. Otherwise: discuss!
>
> Cheers
> Uneron
MestreLion
Nov 15, 2012, 8:34:00 PM11/15/12
to endgame-sin...@googlegroups.com
At 22:03 15/11/2012, you wrote:
First off: Sorry for the Necro, but it seems silly to make a new topic.
Necros are welcome, do the same when discussing things like i18n, options
screen, etc, since old topics carry history about discussions I had with
phil and emh about these subjects.
I've read through MestreLions link and I think the licensing should always kept with the times. Therefor I would like to change the LICENSE file accordingly.
As I said before, my opinion is: "GPL.txt" renamed to
"LICENSE" (no .txt), updated to GPLv3 content, and optionally
using windows line terminators (\r\n)
As for the license headers in each file: Do we really need those? Seems a bit excessive. Wouldn't be a single copyright and licensing statement in the Readme or something, enough? Lets get rid of all the licensing headers!
Errr, not that simple, for 2 reasons: a minimal header, even if not
required, is desirable. It should state what file is this, what project
belongs to, what is the license used, and the famous "no
warranty" disclaimer.
And the second reason is: we can not remove the copyright notice, as it is mandatory per the GPL. To do so we would *have* to hunt down everyone listed in every file. You don't want to do that :P
But we *can* prevent the copyright line from growing further. That's why I suggested to keep only current names and not adding anyone else.
But hey, it's a 17-line header, not that bad at all. Here is a template I applied in certain key files (./singularity.py, code/singularity.py and code/g.py) and suggest standartizing in others, with per-paragraph rationale:
#file: code/g.py
#Copyright (C) 2005 Evil Mr Henry, Phil Bordelon, FunnyMan3595, MestreLion
#This file is part of Endgame: Singularity.
3 lines, 3 goals achieved: file is identified, mandatory Copyright notice with a single year (first release), and few authors, and the notice that this file is part of a larger suite (the E:S project). We could optionally add to the 3rd line: "See AUTHORS, README and LICENSE for a complete list of contributors and licensing information", or whatever fits in 80 chars.
#Endgame: Singularity is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2 of the License, or
#(at your option) any later version.
The license used is clearly stated: GPLv2+, along with its general usage. This is part of the GPLv2 boilerplate
#Endgame: Singularity is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
Another boilerplate: "use at your own risk, don't sue me"
#You should have received a copy of the GNU General Public License
#along with this program. If not, see < http://www.gnu.org/licenses/>.
#A full copy of this license is provided in GPL.txt
This one is optional, since we *do* provide a full copy of the license, so maybe only the 3rd line should be used. And maybe it can be changed to this:
#A full copy of the GNU General Public License is provided in
#LICENSE file. If not, see < http://www.gnu.org/licenses/>. Also see
#README and AUTHORS files for full copyright notices and credits.
Same lenght but more information.
#This file contains all global objects.
Now that is one is *really* important. Not for copyrght or licensing issues, but to answer the most basic question every (new) developer does when facing a new project: *what the hell this file is for?*
Some examples:
code/singularity.py:
#This file sets up initial values from command line and preferences file,
# initialize hardware, load data files and show main screen. Do not execute it
# directly. use ../singularity.py instead.
./singularity.py:
#This file is the starting file for the game. Run it to start the game.
Also notice this template uses GPLv2+ boilerplates. If we all agree to switch to GPLv3, don't forget to use updated boilerplates.
And the second reason is: we can not remove the copyright notice, as it is mandatory per the GPL. To do so we would *have* to hunt down everyone listed in every file. You don't want to do that :P
But we *can* prevent the copyright line from growing further. That's why I suggested to keep only current names and not adding anyone else.
But hey, it's a 17-line header, not that bad at all. Here is a template I applied in certain key files (./singularity.py, code/singularity.py and code/g.py) and suggest standartizing in others, with per-paragraph rationale:
#file: code/g.py
#Copyright (C) 2005 Evil Mr Henry, Phil Bordelon, FunnyMan3595, MestreLion
#This file is part of Endgame: Singularity.
3 lines, 3 goals achieved: file is identified, mandatory Copyright notice with a single year (first release), and few authors, and the notice that this file is part of a larger suite (the E:S project). We could optionally add to the 3rd line: "See AUTHORS, README and LICENSE for a complete list of contributors and licensing information", or whatever fits in 80 chars.
#Endgame: Singularity is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2 of the License, or
#(at your option) any later version.
The license used is clearly stated: GPLv2+, along with its general usage. This is part of the GPLv2 boilerplate
#Endgame: Singularity is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
Another boilerplate: "use at your own risk, don't sue me"
#You should have received a copy of the GNU General Public License
#along with this program. If not, see < http://www.gnu.org/licenses/>.
#A full copy of this license is provided in GPL.txt
This one is optional, since we *do* provide a full copy of the license, so maybe only the 3rd line should be used. And maybe it can be changed to this:
#A full copy of the GNU General Public License is provided in
#LICENSE file. If not, see < http://www.gnu.org/licenses/>. Also see
#README and AUTHORS files for full copyright notices and credits.
Same lenght but more information.
#This file contains all global objects.
Now that is one is *really* important. Not for copyrght or licensing issues, but to answer the most basic question every (new) developer does when facing a new project: *what the hell this file is for?*
Some examples:
code/singularity.py:
#This file sets up initial values from command line and preferences file,
# initialize hardware, load data files and show main screen. Do not execute it
# directly. use ../singularity.py instead.
./singularity.py:
#This file is the starting file for the game. Run it to start the game.
Also notice this template uses GPLv2+ boilerplates. If we all agree to switch to GPLv3, don't forget to use updated boilerplates.
On a related matter: Is it really necessary for every contributor to note down his/her copyright? I mean, we are talking about an GPL project here.
We don't, and we shouldn't. But we also cannot remove current copyrighters, since this would violate the GPL license, unless we ask for their permition individually. But we could set a policy not to add anyone else besides current authors, and keep the future contributors to the AUTHORS and README files.
We can also check other larger projects (like Wine, Gnome, etc) to see how they deal with crediting and copyright notices.
In a nutshell: Update the licensing, get rid of the bulky licensing headers and put all the copyright information into a central file (AUTHORS perhaps, or CREDITS, or something).
AUTHORS is the traditional name for such file. And maybe we could move
the licensing headers for fonts, polib, images, etc, currently in README,
to AUTHORS.
This way README would be more of a user-oriented file, and the legalese is kept separately. The "Credits" section can still be in readme, since that one is a more "informal" listing, where we can also add minor contributors, special thanks, and general credits.
This way README would be more of a user-oriented file, and the legalese is kept separately. The "Credits" section can still be in readme, since that one is a more "informal" listing, where we can also add minor contributors, special thanks, and general credits.
If I get an OK I would commit these changes. Otherwise: discuss!
Those were my 2 cents. Phil, Emh, your turn! :)
On Sunday, May 13, 2012 7:40:53 AM UTC+2, Mestre Lion wrote:
MestreLion
Nov 15, 2012, 8:48:14 PM11/15/12
to endgame-sin...@googlegroups.com
At 22:36 15/11/2012, you wrote:
>After a bit of research, it looks like a main reason for having per-file
>copyright headers is to retain copyright when a file gets separated from
>the main project. This was said in context of utilities and libraries,
>though, where a useful function may be copied, without bringing along the
>entire project. For a game, I think this is much less of a potential
>concern.
True, but the "removable" boilerplates are only 8-lines long, 9 if you consider the separator. We could replace them for something generic like "Endgame:Singularity is licensed under the GPL, version 2 or above. For full credits, copyright and licensing information, see README, AUTHORS and LICENSE files", but this alone takes 2-3 lines, we the net gain would be only 6. So not sure if this is worth.
>After a bit of research, it looks like a main reason for having per-file
>copyright headers is to retain copyright when a file gets separated from
>the main project. This was said in context of utilities and libraries,
>though, where a useful function may be copied, without bringing along the
>entire project. For a game, I think this is much less of a potential
>concern.
>As for assigning copyright, I think that's much less of an issue, and even
>if not strictly needed, it's would then be restricted to just one file.
ML
Uneron
Nov 18, 2012, 12:50:25 AM11/18/12
to endgame-sin...@googlegroups.com
>We legally cannot remove the Copyright notice line from individual files, unless we have written permission from everyone cited in each one of them. But even if we do, I think there should be a copyright notice in every file, even if reduced to 2-3 lines.
The more you know... Well lets just keep it from growing then...
>#This file contains all global objects.
>
>Now that is one is *really* important. Not for copyrght or licensing issues, but to answer the most basic question every (new) developer does when facing a new project: *what the hell this file is for?*
Those are absolutely fair and well, of course. Just trying to get rid of that montrous licensing header...
So, how about this 3-line license header then:
So, how about this 3-line license header then:
#This file is part of Endgame: Singularity.
#Licensed under GPLv2+ see LICENSE for details.
#Copyright (C) 2005 Evil Mr Henry, Phil Bordelon, FunnyMan3595, MestreLion
Then in the LICENSE file we could not only include the current GPL, but also that warrenty paragraph. Because we clearly say that its part of a bigger project with a license file included, I guess it should be fine?
Cheers
Uneron
Cheers
Uneron
Reply all
Reply to author
Forward
0 new messages