Re: [fpc-pascal] [OT] GPL Lisence help
Jorge Aldo G. de F. Junior wrote: APIs are not copyrighteable. This was the whole concept around the Google vs Oracle case. No, that was the concept around the current verdict in the case, it could still be overturned by a superior court. APIs are not copyrightable (although they could potentially be protected by patent, or by the DMCA) but chatty description (comments etc.) of them probably is. Remember that Jonas has asked that this thread adjourn to the fpc-other list. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] GPL Lisence help
The engine is a integral and needed part of a car, yet the engine design and production is not necessarely part of the rest of the car production (In very old times, companies like mercedez built only carriages, benz built engines + chassis, eventually they decided to merge to produce both together, something like that if i remember). The idea is that i am perfectly entitled to design something around a product of other company, without infringing their intellectual property. Accessory or obligatory use doesnt matter, as long as the code is distributed separately and each part is clearly identifiable. Regarding the difference between system libraries, how can you differentiate among non-system libraries and system libraries ? This is quite arbitrary. APIs are not copyrighteable. This was the whole concept around the Google vs Oracle case. 2012/7/29 Attila Kinali : > On Sat, 28 Jul 2012 02:28:43 -0300 > "Jorge Aldo G. de F. Junior" wrote: > >> Think about this : Can you think about the relationship of your >> modules versus someone else modules as being intrinsecally the same >> relation between linux and proprietary apps that happen to run in >> linux ? Because (putting informational security concerns besides) the >> userland apps calls kernel routines just like any app would call a >> library routine, the difference is mainly due to security concerns as >> the kernel code must be secured from userland. But as long as this is >> dynamically linked, i dont see "judicial" differences here. > > You have to be very carefull here. You are mixing two different > interface concepts here. For the kernel, its syscall-API is available > to all applications, no matter what their license is. And the basic > Unix kernel API has been implemented in various kernels with differnet > licenses. While if you make a library GPL you define that the API is only > available to applications that are compatible with the GPL. Yes, you can > argue that using the library does not make your application a derived work. > But you cannot argue that you are not allowed to use the library itself. > > And if you have a good lawyer, you can argue that if your proprietary > application is based on a GPL library for which no other replacement > with the same API is available, the library becomes an integral part > of the application. And even if the application cannot be deemed a > derivative work (which would be hard to argue in this case), the > violation of the libraries license is without doubt. And as your > application does not work without this specific library, it is > quite easy to conclude that you knowingly and willingly violated > the license terms of the library. > > > > Attila Kinali > -- > Why does it take years to find the answers to > the questions one should have asked long ago? > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] GPL Lisence help
On Sat, 28 Jul 2012 02:28:43 -0300 "Jorge Aldo G. de F. Junior" wrote: > Think about this : Can you think about the relationship of your > modules versus someone else modules as being intrinsecally the same > relation between linux and proprietary apps that happen to run in > linux ? Because (putting informational security concerns besides) the > userland apps calls kernel routines just like any app would call a > library routine, the difference is mainly due to security concerns as > the kernel code must be secured from userland. But as long as this is > dynamically linked, i dont see "judicial" differences here. You have to be very carefull here. You are mixing two different interface concepts here. For the kernel, its syscall-API is available to all applications, no matter what their license is. And the basic Unix kernel API has been implemented in various kernels with differnet licenses. While if you make a library GPL you define that the API is only available to applications that are compatible with the GPL. Yes, you can argue that using the library does not make your application a derived work. But you cannot argue that you are not allowed to use the library itself. And if you have a good lawyer, you can argue that if your proprietary application is based on a GPL library for which no other replacement with the same API is available, the library becomes an integral part of the application. And even if the application cannot be deemed a derivative work (which would be hard to argue in this case), the violation of the libraries license is without doubt. And as your application does not work without this specific library, it is quite easy to conclude that you knowingly and willingly violated the license terms of the library. Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] GPL Lisence help
Do dynamic linked executables really need to not be GPL ? I mean, application subdivision in modules has nothing to not be accepted at courts as a valid concept. Your module/lib is GPL but code linked to it must not be and this is not a violation of GPL. Provided that the code to your module/lib is sent with the binaries, the rest of code (non-gpl modules) dont need to be provided. software modularization is accepted at courts just like a car subdivision in mechanical modules, at least when they are dynamically linked. Think about this : Can you think about the relationship of your modules versus someone else modules as being intrinsecally the same relation between linux and proprietary apps that happen to run in linux ? Because (putting informational security concerns besides) the userland apps calls kernel routines just like any app would call a library routine, the difference is mainly due to security concerns as the kernel code must be secured from userland. But as long as this is dynamically linked, i dont see "judicial" differences here. Thats my view and i am not a lawyer. 2012/7/27 Mark Morgan Lloyd : > Dimitrios Chr. Ioannidis wrote: >> >> Hi all, >> >> first let me express my apologies for the off topic question. >> >> I'm having trouble to choose the correct gpl lisence for a new open >> source project that i'm starting. I want the project to be open source >> gpl'ed so it can be accepted in distro's like Debian. But, at the same >> time, because the structure is modular, i want the possibility, to be >> used by anyone in commercial applications. >> >> Can anyone give a hint and/or a suggestion ? > > > Possibly multiple licenses: the license is determined by how somebody has > got the code from you irrespective of whether he could have got it > elsewhere. Alternatively, the basic framework is GPL but dynamically-linked > extensions are proprietary. > > I suppose that the bigger question is: how does one find an affordable > lawyer, well-versed in the laws covering the major jurisdictions? > > -- > Mark Morgan Lloyd > markMLl .AT. telemetry.co .DOT. uk > > [Opinions above are the author's, not those of his employers or colleagues] > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] GPL Lisence help
Dimitrios Chr. Ioannidis wrote: Hi all, first let me express my apologies for the off topic question. I'm having trouble to choose the correct gpl lisence for a new open source project that i'm starting. I want the project to be open source gpl'ed so it can be accepted in distro's like Debian. But, at the same time, because the structure is modular, i want the possibility, to be used by anyone in commercial applications. Can anyone give a hint and/or a suggestion ? Possibly multiple licenses: the license is determined by how somebody has got the code from you irrespective of whether he could have got it elsewhere. Alternatively, the basic framework is GPL but dynamically-linked extensions are proprietary. I suppose that the bigger question is: how does one find an affordable lawyer, well-versed in the laws covering the major jurisdictions? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] GPL Lisence help
On Fri, Jul 27, 2012 at 5:39 PM, Dimitrios Chr. Ioannidis wrote: > Hi all, > > first let me express my apologies for the off topic question. > > I'm having trouble to choose the correct gpl lisence for a new open > source project that i'm starting. I want the project to be open source > gpl'ed so it can be accepted in distro's like Debian. But, at the same > time, because the structure is modular, i want the possibility, to be > used by anyone in commercial applications. > > Can anyone give a hint and/or a suggestion ? How about Dual licensed ? Let people choose the license: GPL or MIT ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
