> we were talking about the LGPL, not the GPL in this regard. the
> corresponding section in the FAQ is "How does the LGPL work with Java?".
> With the GPL, a seperate assembly won't help either.
>
> as for the AGPL FAQ question: yes, and this defines when you have to
publish
> the source code of the (modified) AGPL program and everything that links
to
> it (which can only be AGPL or GPL). it is NOT about derived works! (or
> whatever they call that in v3)
it IS about derivative work, as that's the legal term for declaring
what is violating a license.
> if you don't believe me, pls read the license and find the term
> "interacting... remotely" in section 13.
so you're saying that an app utilizing a webservice which is build
using AGPL code is not violating the AGPL? dream on. I agree that that
clause is beyond stupid, but that's not the topic ;)
FB
>
> ________________________________
>
> From: [email protected] [nhibernate-
> [email protected]] on behalf of Ayende Rahien
[[email protected]]
> Sent: Tuesday, September 21, 2010 22:03
> To: [email protected]
> Subject: Re: [nhibernate-development] LGPL v3 for NH3 (?)
>
>
> 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] [nhibernate-
> [email protected]] on behalf of Frans Bouma [[email protected]]
> Sent: Tuesday, September 21, 2010 18:56
>
> To: [email protected] <mailto:nhibernate-
> [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 <http://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
>
