I read this as the assembly containing this class. In cases where the code may require redistribution, I put all the NH derived classes in their own project.
On Tue, Sep 21, 2010 at 10:12 PM, Diego Mijelshon <[email protected]>wrote: > How is a "program" defined in this context? > > That is, if I, for example, subclass Dialect, what is affected by the GPL? > The project that contains the class deriving from Dialect? > The whole solution (I hope not!)? > > Diego > > > > On Tue, Sep 21, 2010 at 17:03, Ayende Rahien <[email protected]> wrote: > >> *http://www.gnu.org/licenses/gpl-faq.html* * >> * >> *In an object-oriented language such as Java, if I use a class that is >> GPL'ed without modifying, and subclass it, in what way does the GPL affect >> the larger program?* >> >> Subclassing is creating a derivative work. Therefore, the terms of the GPL >> affect the whole program where you create a subclass of a GPL'ed class. >> >> *In AGPLv3, what counts as “interacting with [the software] remotely >> through a computer network?”* >> >> If the program is expressly designed to accept user requests and send >> responses over a network, then it meets these criteria. Common examples of >> programs that would fall into this category include web and mail servers, >> interactive web-based applications, and servers for games that are played >> online. >> >> If a program is not expressly designed to interact with a user through a >> network, but is being run in an environment where it happens to do so, then >> it does not fall into this category. For example, an application is not >> required to provide source merely because the user is running it over SSH, >> or a remote X session. >> On Tue, Sep 21, 2010 at 9:51 PM, Wenig, Stefan >> <[email protected]>wrote: >> >>> Deriving a class from an NH class in a different assembly does _not_ >>> create a derived work. That's just a coincidence in language, it's explained >>> in the FAQ (something about java) >>> >>> Calling a service with either GPL or AGPL code will _not_ affect the >>> license of the caller. You got that one wrong again, I recommend you read >>> sections 13 of both GPL and AGPLv3 if you don't take my word for it. >>> >>> And copyleft does make sense. You can argue forever wheter it's more free >>> - that's a matter of definition. But it does have advantages as well as >>> disadvantages. (IMHO strong copyleft is too restrictive for libraries, but a >>> valid choice for applications. but that's just me.) >>> >>> Cheers, >>> Stefan >>> ________________________________________ >>> From: [email protected] [ >>> [email protected]] on behalf of Frans Bouma [ >>> [email protected]] >>> Sent: Tuesday, September 21, 2010 18:56 >>> To: [email protected] >>> Subject: RE: [nhibernate-development] LGPL v3 for NH3 (?) >>> >>> > > yes, that's a good workaround. Likely also the route Steve's >>> customer >>> > > should take in this: any modifications to NH, extension classes to >>> NH, >>> > > place that in an LGPL-ed assembly and the bigger app isn't affected. >>> > >>> > Modifications yes. What are extension classes? Neither derived, >>> injected >>> or >>> > any other classes of your own authorship must be LGPL. Extension >>> methods >>> > neither. The key is that the modified LGPL code must still compile and >>> work >>> > as a module. >>> >>> Extension classes which derive from a base class from NH, that >>> could >>> be a problem, but that's also a small thing: does that 1 class link make >>> it >>> a derivative work? >>> >>> > > > The web services part is for the AGPL, not the GPL or LGPL, IIRC. >>> > > > There are explicit ways to break the links, anything that is out of >>> > > process >>> > > > (cmd line, pipes, etc). >>> > > >>> > > Oh! you're right, I forgot about that one, indeed. AGPL (A stands >>> for >>> > > aggressive? ;)) was the insane one. >>> > >>> > A stands for Affero, the original inventor. The name was kept so that - >>> > guess what - the license condition "Affero GPL 2.0 or higher" would >>> work >>> for >>> > the "GNU Affero GPL v3" ;-) >>> > >>> > But you're confusing two things here. The AGPL does not say that >>> copyleft >>> > extends over web service boundaries. It only says that if you provide >>> an >>> > modified AGPL app "as a service" (in the SaaS sense, not necessarily >>> SOAP- >>> > like), you must provide the source code. The GPL alone would not >>> protect >>> the >>> > authors from a third party "stealing" and extending their code and >>> selling >>> > it as a service without giving back the code. That makes perfect sense. >>> >>> it's an insane clause, as a big UI app using a service with 2 GPL >>> classes behind it doesn't make the app a derivative work per se of the 2 >>> classes. BUt alas, I find all copyleft licenses odd: if you want to give >>> away your code, use BSD or apache, it's the license which embeds the >>> spirit >>> of giving away your work for others, not the rule ridden FSF playgound. >>> >>> > The AGPL is also the preferred license for dual licensing (we do that). >>> >>> any license is suitable for that, you own the code, you decide how >>> to license it. You can distribute it under 10 licenses, it's your work, >>> you >>> decide. >>> >>> > > system links to it... violation? Judges really won't understand that, >>> > > most of them can barely handle modern things like keyboards and mice. >>> > > ;) >>> > >>> > They will use an expert witness. Good luck, still... >>> >>> even then... from own experiences as an expert witness for >>> software >>> related matter, it takes ages to explain simple things to them, as they >>> don't have a beta-mindset and have no clue how a computer works, what >>> software does etc. Relying on their judgment in cases like this is IMHO a >>> fatal mistake. It of course also depends on whether your countries' >>> system >>> uses juries (ours doesn't) or not. >>> >>> > > > Actually, that scenario is safe. You aren't distributing your >>> > > changes. >>> > > >>> > > if you create the website for a client, you do. Many consultants >>> > > don't get this, but creating software for a 3rd party IS >>> distribution. >>> > >>> > No, the GPL permits you to have a contractor build private stuff for >>> you >>> -> >>> > no need to give away the source code. >>> >>> true. >>> >>> > > > IIRC, the MySQL stance is that if you can use the app with more >>> than >>> > > 1 db, >>> > > > it doesn't apply. >>> > > >>> > > Interesting. A new view on the matter. All their lawyers ever >>> could >>> > > tell me was 'of course you're in violation in that situation. You can >>> > > overcome that by becoming a VAR'... >>> > >>> > Here's a lot of room for interpretation. If you use a standard >>> interface, >>> > you're not infringing on any concrete implementation's copyright. If >>> you, >>> > however, distribute that implementation along with yours, it gets >>> > complicated. That's why some OSS SW requires you to get other OSS >>> modules >>> > from the original source, like Moonlight and the free codecs... >>> > >>> > There are other grey areas. E.g., the FSF's GPL FAQ says this: >>> > "If the program dynamically links plug-ins, but the communication >>> between >>> > them is limited to invoking the 'main' function of the plug-in with >>> some >>> > options and waiting for it to return, that is a borderline case." >>> >>> Hmm. >>> >>> Well I asked MySQL about this situation with DbProviderFactory, >>> and >>> they told me "you have to GPL your driver", even though my driver is a >>> piece >>> of code which uses dbproviderfactory, has no reference to mysql's >>> ado.net >>> provider and for example also works with devart's mysql direct by >>> changing a >>> string in a config file. >>> >>> Indeed a grey area! It's sad so much confusion is created by >>> various >>> parties in this, it doesn't make it easier for developers to make >>> well-informed decisions. >>> >>> FB >>> >> >> >
