flat assembler
Message board for the users of flat assembler.

Index > Heap > Discussion about Fresh IDE license change

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
JohnFound wrote:
Hm, I already read this statement somewhere, but never understood. IMHO, it is some kind of paranoia.

I wish it were Smile

JohnFound wrote:
AFAIK, the static linking to the unmodified version of LGPL should be OK. Of course, the modified version of the library should be published under LGPL but it is normal.

Can you point me to some additional info about this subject?

Right, again I'll stick with version 2, as I haven't really looked into version 3 - so, LPGLv2.1.

We'll start with Section 5, since that's where the interesting things start happening, the license is relativley innocuous until then (Section 2 seems somewhat restrictive at first glance, but I believe it's targeted at modifications to the library code). Snip:
Quote:
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License.

So, as long as your program is in object form, the LGPL doesn't cover it... however, as soon as you link that object file with the library to produce an executable, your program goes from "work that uses the Library" to "derivative of the Library", even if there's no modifications to the library. Also, keep in mind that static vs. dynamic linking is a bit of a hornet's nest in the GPL world - generally, "in the same address space" is interpreted as "the same program".

Section 6 is pretty much what specifies "so, I can hardly avoid falling into your trap - what can I do, to keep my closed-source code proprietary?". Let's start with the first paragraph from Section 6:
Quote:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

So, you have to permit reverse engineering and a way to update the library used in the closed-source executable. Section 6 defines two ways to comply with that: 6.a) release "source code or object files so we can relink" for the proprietary parts, or 6.b) link to the LPGL library as DLL (aka shared library).

Now, I understand why they're doing this - it's not just about keeping the library source code open, they want to give the end-user the... freedom... to replace the LGPL part of the program with a modified version - fair enough, I guess. But it does mean you can only safely mix proprietary and LGPL if you link dynamically.

_________________
Image - carpe noctem
Post 03 Feb 2013, 11:42
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Ah, I see the problem. LGPL covers the compiled binary together with the source and treat them equally.

Then I need such a license, that to be strong copyleft for the source code and to allow the compiled binary to be distributed as licensed under different license. At least for FreshLib.

I read a hint, that EUPL possibly allows such a treat of the source code. I have to read more...
Post 03 Feb 2013, 12:11
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
I always wonder how this license thing works in software.

What if somebody gets your source code, deletes the GPL (or whatever) text from it, and keep using it for commercial stuff without telling anyone.

How will you even know it?
Post 04 Feb 2013, 00:02
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8900
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
if the commercial product doesn,t get huge attraction, maybe nobody would know, except the programmer himself.

i just wonder,
could i license how to walk from my house to nearest petrol station? and GPL the route?

i code an application to perform a certain function.
compile it into machine code,
basically all the jmp, mov, binary processing

how different is to be different?

i dump ms visual studio 2012 latest asm code, copy its asm implementation into my fasm program, i reverse its uses of EDI ESI, still obtain same result.

maybe ms can sue me? and how could there be thousand of optimize methods to calculate string length?

maybe best way to protect all the intellectual property is masking it with .net / jvm
add several vm dynamic registers,

now hardly to copy their IP code to native x86 / x64 implementation.
Post 04 Feb 2013, 00:30
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Post 04 Feb 2013, 01:53
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
For fasm core I did not want to use a copyleft license and I thus chose the permissive BSD license as the base. I uphold it, I do not want fasm's core to be copyleft - if you want to integrate it into a GPL-licensed program, the only way may be to treat it like a GPL-incompatible library that keeps its own license.
Post 05 Feb 2013, 19:21
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Tomasz Grysztar wrote:
For fasm core I did not want to use a copyleft license and I thus chose the permissive BSD license as the base. I uphold it, I do not want fasm's core to be copyleft - if you want to integrate it into a GPL-licensed program, the only way may be to treat it like a GPL-incompatible library that keeps its own license.


Yes, I understand that. You know even now the FASM part in Fresh IDE has its own license and this is OK with the current Artistic license.

Unfortunately the license of FASM is not BSD, because of the last clause. If it were, it would be compatible with copyleft licenses. Well, at least one way. Smile

I am still studying how such combination can be done.
Of course if it is impossible, Fresh IDE will be licensed under some permissive license - probably the same as for FreshLib.

Any ideas how this situation can be solved?

And one observation - the greatest problem with copyleft licenses is that they treat the compiled binaries together with the source. For example, FASM compiler in Fresh has its own directory tree and is totally independent from the IDE itself. So, it is possible to license the compiler and the IDE with even incompatible licenses.
But once the IDE is compiled, the result EXE contains both sources, so if this binary have to be licensed - it causes a conflict.
I wonder, is it possible to license the binary separately? Smile

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 05 Feb 2013, 19:54
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
JohnFound wrote:
I wonder, is it possible to license the binary separately? Smile

Nope, but it should be possible to include (non-GPL'ed) fasm as you are currently doing, I think I outlined that previously... but it does mean that you need the permission of all current copyright holders (which you do anyway, to move to GPL license), and it also means you can never include any other piece of GPL/LGPL software (without getting OK from all the copyright holders of those projects).

I hope it's clear why GPL is often referred to as viral Smile

_________________
Image - carpe noctem
Post 05 Feb 2013, 20:31
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:42; edited 2 times in total
Post 05 Feb 2013, 20:45
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
f0dder wrote:
Nope, but it should be possible to include (non-GPL'ed) fasm as you are currently doing.


Hm, I am not sure I understand you correctly. The original GPL is one-way compatible with BSD - GPL projects can use BSD code and to distribute the result as GPL. (The original code still will be distributed under BSD of course).

Unfortunately, because of the last clause in FASM License, this way is not possible for Fresh.

Even more, as long as Fresh IDE can be considered "derivative work", then it seems that Fresh IDE should be licensed under FASM license:

[quote]The licence and distribution terms for any publically available
version or derivative of this code cannot be changed. i.e. this code
cannot simply be copied and put under another distribution licence
(including the GNU Public Licence).[/code]

So, it came out that FASM license is copyleft, or what? Smile

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 05 Feb 2013, 21:04
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
JohnFound wrote:
Hm, I am not sure I understand you correctly. The original GPL is one-way compatible with BSD - GPL projects can use BSD code and to distribute the result as GPL. (The original code still will be distributed under BSD of course).

Unfortunately, because of the last clause in FASM License, this way is not possible for Fresh.

Indeed it isn't, if using GPL as-is without adding an exception. See the "workaround" link (debian mailing list) and the two gpl-faq links after that.

As I understand it, you license the whole work under GPL, but grant an exception that allows people to use the oh-so-tainted-dirty-nongpl-licensed FASM code in your work. This keeps the original FASM license. If people fork Fresh, they can remove the exception - that doesn't mean FASM is suddenly licensed under GPL, it means that fork (and derivative code) is no longer allowed to include FASM.

IANAL, but I expect Debian to have a pretty good grip on legal matters - they actually care about this stuff Smile. But to be 100% sure, you could contact the FSF about the matter, giving a quick description of the problem, mentioning the Debian-legal thread, and perhaps this thread as well, just to be sure.

_________________
Image - carpe noctem
Post 05 Feb 2013, 21:18
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
I strongly dislike the idea to add exceptions. IMO, it is better to use non copyleft license than to work through exceptions and special cases.
Post 05 Feb 2013, 21:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
JohnFound wrote:
I strongly dislike the idea to add exceptions. IMO, it is better to use non copyleft license than to work through exceptions and special cases.

I can understand that - but if GPL+exception-for-fasm most closely matches the wishes you have for what people can do with the code (i.e., forcing people to keep Fresh itself in the open), I would reckon it's not a bad choice to make (and perhaps even better than finding an alternative license). After all, GPL has been around for quite a while, a lot of thought has gone into it, and there's been successful cases of defending it in court.

Also, before anybody brings it up: in case you use FreshLib in Fresh, you can dual-license it, so that it's GPL in "the complete work" (aka Fresh + FreshLib), but you specifically grant a more permissive license for that exact part as well. Not sure about the details of how to package stuff, but it should definitely be doable Smile

_________________
Image - carpe noctem
Post 05 Feb 2013, 21:38
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Quote:

I am still studying how such combination can be done.

I think that the best way is the dll way. Fresh can dynamically link to a special fasm.dll with the same Fasm Artistic License. The dll will have all the interface services that Fresh is currently using, such as code analyzers, preprocessing and assembling.

The main advantage is to have the possibility to use different releases and even different assemblers with the same IDE. It is easier to mantain because it will impose a strong interface definition since the beginning.

Other advantage is that the dll will serve for other IDEs, backend for compilers, etc...
Post 05 Feb 2013, 21:45
View user's profile Send private message Yahoo Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
pelaillo wrote:
I think that the best way is the dll way. Fresh can dynamically link to a special fasm.dll with the same Fasm Artistic License. The dll will have all the interface services that Fresh is currently using, such as code analyzers, preprocessing and assembling.

If JohnFound sticks with the artistic license, there's no reason to go the DLL way, as it and the fasm licenses are compatible.

If he chooses to go GPL, simply using FASM.DLL is not an option, the issue of DLLs has already been widely covered (perhaps not here, but you don't have to go further than the gpl-faq). He'd have to use FASM.EXE instead, which would be OK.

pelaillo wrote:
The main advantage is to have the possibility to use different releases and even different assemblers with the same IDE. It is easier to mantain because it will impose a strong interface definition since the beginning.

Other advantage is that the dll will serve for other IDEs, backend for compilers, etc...

Those are completely different from the licensing issue, though Smile - and I'd expect Fresh to be pretty heavily tied to FASM? Wonder if there's any reason to change that, there's a lot of other IDEs around if you want something polygot.

_________________
Image - carpe noctem
Post 05 Feb 2013, 21:51
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
f0dder wrote:
Also, before anybody brings it up: in case you use FreshLib in Fresh, you can dual-license it, so that it's GPL in "the complete work" (aka Fresh + FreshLib), but you specifically grant a more permissive license for that exact part as well. Not sure about the details of how to package stuff, but it should definitely be doable Smile


FreshLib is not a problem. It will be licensed under permissive license, compatible with copyleft licenses - probably BSD. In this case I don't have to do anything - re-licensing becomes automatically.

@pelaillo - using DLL is possible, but useless. Fresh IDE is very closely connected to FASM and probably can't be used with other assemblers (or at least without losing most of its advanced features) so, why to split the monolith application only because of license issues?

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 05 Feb 2013, 21:59
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
ejamesr



Joined: 04 Feb 2011
Posts: 52
Location: Provo, Utah, USA
ejamesr
In general, it's good to have some form of license in any case. I'm not a lawyer, but I've been involved in a few intellectual-property (IP) battles and so I've become aware of a few issues regarding IP.

Without a specified license, local laws regarding IP may specify various default (restrictive) rules or policies that the creator of the IP item may not be aware of. So IMHO, in many (most?) cases you will need a written license in order to make things "free" for others to use (and your license can, of course, define what "free" means).

Also, many companies will refuse to use products unless they come with a license (which is also acceptable).

FWIW...
Post 07 Feb 2013, 22:50
View user's profile Send private message Send e-mail Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8900
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
could anyone explain to me,

the license covers what?
the fresh ui? fresh library, fresh source code,

how many copy of same sequence flow instructions that made up i must use its license? assume i copy same here and there and use it in my program?

or i see how he tackle a problem, i use that idea but minus away some instructions.
Post 08 Feb 2013, 01:33
View user's profile Send private message Reply with quote
ASM-Man



Joined: 11 Jan 2013
Posts: 65
ASM-Man
I dislike GPL licence really. I have learned to hate it. Why? if you make your program open source,I think that you are giving the rights to the peoples make what he/she want to. No more restrictions must be done. Please, don't get me wrong. It's IMHO.
Post 08 Feb 2013, 02:59
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
The more I read, the more I like EUPL. Here is one quote, not from the license, but from explanatory article Q/A style. The highlights are mine:

Quote:
Q: Can I merge other software with EUPL software?

A:
Yes, you can merge EUPL software or any part or component of it with other software, provide this other software is yours (developed by you or for you) or was licensed to you under licensing terms allowing you to do so (which is the case with all Open Source software).

Please note that the question of how far software can be considered as “merged” is a matter of case to case appreciation. Merging criteria (or criteria to consider that a new software is a derivative) are not precisely defined in the EUPL, because it was not reasonable, due to the diversity of possible situations.

In most cases, simply aggregating, combining or linking software does not create a derivative.

Whenever possible, it is recommended that the different components exchange parameters or data without merging their source code into a single file. This would preserve modularity, facilitate future improvements and prevent licence compatibility issues in the case of re-distribution as the different components can then be used and possibly be re-distributed under their respective different licences.


If it is not possible to avoid the merging of the different codes within a single file, you will not encounter problems if you are using the merged software for your own needs (no distribution outside your organisation). However, if your intention is to distribute the merged software to third parties under the EUPL licence or to perform it publicly (for example by providing a service with it on the Internet), the pre-requisite is to check if the licensing conditions of the merged software are compatible.

To help you, Joinup publishes a list or matrix of licences that are compatible with the EUPL.

There is no problem if you have the copyright of the other software: the merged software is a derivative work that can be re-distributed under the EUPL.

There is no problem if the other software licensing conditions are permissive regarding the re-distribution under the EUPL (this would be the case if the merged component was licensed to you under a BSD or a MIT licence, for example).

At the contrary, if these licensing conditions are restrictive or “copyleft” (allowing no re-distribution under any other licence than the original one), you should check if this licence is included into the EUPL compatibility list. If this is the case (for example if the other software was licensed to you under GPL v. 2), there are no problems either: you are authorised to re-distribute the merged software under the compatible licence.

In other cases no re-distribution will be possible without a specific authorisation from all relevant authors.

Some authors distributing components under a "copyleft" licence have implemented "FOSS exception lists" to authorise the distribution of larger (combined) derivative works under another FOSS licence. For example Oracle has included the EUPL in its FOSS exception list (for integrating MySQL components that are distributed under the Gnu GPLv2).


IMHO, this should be enough to protect FASM source code from re-licensing and will allow using Fresh IDE itself under any EUPL compatible license - i.e. strong copyleft.

Additional advantage of EUPL is that it is created concerning Europe law and has 22 official translations: read them here.


Any thoughts on this matter?

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 08 Feb 2013, 12:51
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.