Licensing and the library version of git

Licensing and the library version of git

[Jon Smirl]

Can the library version of git be licensed LGPL instead of GPL? If it
is GPL then it can't be linked into non-GPL projects like Eclipse.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Licensing and the library version of git

[Shawn Pearce]

Jon Smirl <jonsmirl@gmail.com> wrote:
> Can the library version of git be licensed LGPL instead of GPL? If it
> is GPL then it can't be linked into non-GPL projects like Eclipse.

True.  But I have a pure-Java implementation of portions of GIT:

	- pack file reader, including delta decompression;
	- loose object reader (sans new pack header format);
	- loose object writer (blobs, trees, commits, no tags);
	- ref reader/basic resolver;
	- ref writer;
	- new repository creation;
	- tree and commit parsing;
	- n-way tree structure diff (no blob content diff);

and Eclipse UI for:

	- resource decorator showing object state;
	- rename tracking (well, automatic delete then add);
	- add file/folder to repository;
	- delete file/folder from repository;
	- save workspace state to a tree;
	- periodically flush modified files into blobs;

but I need UI still for creating a commit.  I'd like to get that
code finished this week and get the repository posted on the web
for others to start messing around with if they are interested.
This project has just been slow going for me as I'm working looooong
hours at my day job.  :-)

-- 
Shawn.

Re: Licensing and the library version of git

[Petr Baudis]

Dear diary, on Wed, Jul 26, 2006 at 11:36:16PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> Can the library version of git be licensed LGPL instead of GPL? If it
> is GPL then it can't be linked into non-GPL projects like Eclipse.

Probably not since it essentially _is_ the base Git code now. You would
need to find all the Git copyright holders and convince them to
relicence it, since there are thoughts about moving more code to the
library, and even parts of scripts might eventually end up there after
rewrite in C.

And I didn't even get to discussing whether LGPL is actually desirable
for Git.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Petr Baudis wrote:

> And I didn't even get to discussing whether LGPL is actually desirable
> for Git.

... or whether it is neccessary for an Eclipse-plugin to something else 
than GPL.

Ciao,
Dscho

Re: Licensing and the library version of git

[Jon Smirl]

On 7/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 27 Jul 2006, Petr Baudis wrote:
>
> > And I didn't even get to discussing whether LGPL is actually desirable
> > for Git.
>
> ... or whether it is neccessary for an Eclipse-plugin to something else
> than GPL.

Eclipse is not licensed GPL. To use the git library with Eclipse it
would need a JNI wrapper which would link it into the code. The work
around would be to make the user compile and link the JNI wrapper. But
I see that someone is already writing a pure Java version which will
work around the GPL problem assuming the Java version is released
under a compatible license.

In general libraries should be licensed LGPL to avoid the license
incompatibility problem. A GPL library forces the main app to be GPL
too. You may like trying to force GPL onto the app but many apps are
stuck with the license they have and can't be changed since there is
no way to contact the original developers. A GPL git library means
that these apps simply won't use git.

This also means that there will never be integrated git support in
Microsoft Visual Studio. This has impacts on switching cross platform
apps like Mozilla to git.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Licensing and the library version of git

[Petr Baudis]

Dear diary, on Thu, Jul 27, 2006 at 02:54:54PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> In general libraries should be licensed LGPL to avoid the license
> incompatibility problem. A GPL library forces the main app to be GPL
> too.

But really another main app here (Git) is ending up in the library.

You can still always use the "Git ABI" - the commands. Or you could try
having a GPL'd "Git/Eclipse toolkit" which would reduce the barrier to
only single exec per Git invocation or something, but it would be
probably somewhat tricky on the derived works playground.

> You may like trying to force GPL onto the app but many apps are
> stuck with the license they have and can't be changed since there is
> no way to contact the original developers.

At this point, git-shortlog lists exactly 200 people (at least entries
like Unknown or No name are all linux@horizon.com ;-).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Licensing and the library version of git

[Jon Smirl]

On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
> > You may like trying to force GPL onto the app but many apps are
> > stuck with the license they have and can't be changed since there is
> > no way to contact the original developers.
>
> At this point, git-shortlog lists exactly 200 people (at least entries
> like Unknown or No name are all linux@horizon.com ;-).

Inability to integrate with Microsoft Visual Studio is going to have a
lot of impact on the cross platform use of git.  Is a conscious
decision being made to stop this integration or is this just unplanned
side effect of the original license? If this is an unplanned side
effect, the quicker we move, the easier it is to fix.

Note that only the code going into the library needs to be LGPL. That
should significantly reduce the number of authors that need to be
contacted.

A first step to fixing this would be to add an immediate requirement
that all new code that is targeted to library functions be licensed
LGPL. That will at least stop the problem from getting any worse.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Jon Smirl wrote:

> On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
> > > You may like trying to force GPL onto the app but many apps are
> > > stuck with the license they have and can't be changed since there is
> > > no way to contact the original developers.
> > 
> > At this point, git-shortlog lists exactly 200 people (at least entries
> > like Unknown or No name are all linux@horizon.com ;-).
> 
> Inability to integrate with Microsoft Visual Studio is going to have a
> lot of impact on the cross platform use of git.  Is a conscious
> decision being made to stop this integration or is this just unplanned
> side effect of the original license? If this is an unplanned side
> effect, the quicker we move, the easier it is to fix.

If you want to do it, go ahead. I think the reason it has not been done so 
far is that nobody had the need, or alternatively was not ready to do 
it or hire someone to do it.

> Note that only the code going into the library needs to be LGPL. That
> should significantly reduce the number of authors that need to be
> contacted.

No and no.

Let me tackle the second point first: Almost all functionality is in the 
library, and more is to be transferred to it.

The first point: If you want to integrate git into MSVC, you have to 
provide it via the SCCI. Note that the letter "I" stands for "Interface", 
which makes a runtime linking with the component a non-derivative work. 
Which basically means that you need not GPL MSVC.

> A first step to fixing this would be to add an immediate requirement
> that all new code that is targeted to library functions be licensed
> LGPL. That will at least stop the problem from getting any worse.

If you still feel the need for LGPL, go ahead, find all contributors and 
contact them.

Ciao,
Dscho

Re: Licensing and the library version of git

[Linus Torvalds]

On Thu, 27 Jul 2006, Jon Smirl wrote:
> 
> Inability to integrate with Microsoft Visual Studio is going to have a
> lot of impact on the cross platform use of git.  Is a conscious
> decision being made to stop this integration or is this just unplanned
> side effect of the original license? If this is an unplanned side
> effect, the quicker we move, the easier it is to fix.

I don't think the choice of GPLv2 is an "unplanned side effect". It's a 
fact.

I personally don't much like the LGPL.

I'd also like to point out that unlike every single horror I've ever 
witnessed when looking closer at SCM products, git actually has a simple 
design, with stable and reasonably well-documented data structures. In 
fact, I'm a huge proponent of designing your code around the data, rather 
than the other way around, and I think it's one of the reasons git has 
been fairly successful (*).

So it's easy enough to just write whatever Java code or something to just 
access the databases yourself. The object model of git may be smart, but 
it's neither proprietary nor patented. I suspect it's often a lot easier 
to integrate git into other projects _that_ way, rather than try to 
actually port the code itself.

		Linus

(*) I will, in fact, claim that the difference between a bad programmer 
and a good one is whether he considers his code or his data structures 
more important. Bad programmers worry about the code. Good programmers 
worry about data structures and their relationships.

Re: Licensing and the library version of git

[Linus Torvalds]

On Thu, 27 Jul 2006, Linus Torvalds wrote:
>
> I'd also like to point out that unlike every single horror I've ever 
> witnessed when looking closer at SCM products, git actually has a simple 
> design, with stable and reasonably well-documented data structures.

Side note: they got even cleaner with the recent 'objformat' merge, where 
the unpacked objects now have the same format as the packed ones. I'd 
suggest that if somebody is interested in duplicating git functionality, 
they should start with the new format, and thus be able to share more 
code.

Also note that a lot of the really _core_ and complex git functionality 
(notably, the revision list parsing, which is really all of the truly 
fundamental stuff) is probably not something that a project like Visual 
Studio or an Eclipse plugin would ever even want.

I seriously doubt that Eclipse or Visual Stupido could ever actually 
_understand_ what git does, so the only parts you actually would want to 
use for those is literally the trivial stuff - the "look up objects" and 
"generate commits" part. 

			Linus

Re: Licensing and the library version of git

[Jakub Narebski]

Linus Torvalds wrote:

> I seriously doubt that Eclipse or Visual Stupido could ever actually 
                                    ^^^^^^^^^^^^^^
Visual Stupido... nice typo :-D

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Licensing and the library version of git

[Jon Smirl]

On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I seriously doubt that Eclipse or Visual Stupido could ever actually
> _understand_ what git does, so the only parts you actually would want to
> use for those is literally the trivial stuff - the "look up objects" and
> "generate commits" part.

Typically an integrated IDE can move, delete, rename directories and
files. Get a log. Push, pull and commit. Revert a change. Generate
diffs to previous versions.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Licensing and the library version of git

[Anand Kumria]

On Thu, 27 Jul 2006 13:47:24 -0400, Jon Smirl wrote:

> On 7/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> I seriously doubt that Eclipse or Visual Stupido could ever actually
>> _understand_ what git does, so the only parts you actually would want to
>> use for those is literally the trivial stuff - the "look up objects" and
>> "generate commits" part.
> 
> Typically an integrated IDE can move, delete, rename directories and
> files. Get a log. Push, pull and commit. Revert a change. Generate
> diffs to previous versions.

Kind of what you can do via CVSNT and git-cvsserver, no?

Anand

Re: Licensing and the library version of git

[Grzegorz Kulewski]

On Thu, 27 Jul 2006, Linus Torvalds wrote:
> So it's easy enough to just write whatever Java code or something to just
> access the databases yourself. The object model of git may be smart, but
> it's neither proprietary nor patented. I suspect it's often a lot easier
> to integrate git into other projects _that_ way, rather than try to
> actually port the code itself.

But won't it create hell of several buggy, incompatible, not well 
maintained versions of GIT (or at least GIT "client")?

I think that part of the anwser for question "Why do people use GIT?" is 
that they trust you and other maintainers that you do a good and stable 
job. Won't creating several ports/forks/whatever destroy at least part of 
this?

Besides it is a whole lot easier to just create some JNI code around 
libgit and use it from Java than to rewrite GIT (or part of it) in Java or 
in any other language. Also resulting code is likely to be (maybe not very 
much but still) faster.


Thanks,

Grzegorz Kulewski

Re: Licensing and the library version of git

[Linus Torvalds]

On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> 
> I think that part of the anwser for question "Why do people use GIT?" is that
> they trust you and other maintainers that you do a good and stable job. Won't
> creating several ports/forks/whatever destroy at least part of this?

Sure. But the point is, the GPLv2 isn't exactly up for discussion. People 
can complain all they want, but if they want to trust me, they'll take the 
GPLv2. It's that easy.

And if people don't want the GPLv2, they have alternatives as outlined. 
Yes, their code will be less reliable and good, but hey, that's kind of my 
_point_. A lot of the quality of open source projects comes from the fact 
that you see how it gets used, and the LGPL is strictly inferior, because 
it ends up hiding all the _important_ parts behind a veil of impenetrable 
secrecy.

Quite frankly, I don't want to see bug-reports and interfaces that I can't 
actually duplicate and follow myself. I'm so _totally_ uninterested in 
those kinds of things that it's not even funny.

			Linus

Re: Licensing and the library version of git

[Daniel Barkalow]

On Thu, 27 Jul 2006, Linus Torvalds wrote:

> On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> > 
> > I think that part of the anwser for question "Why do people use GIT?" is that
> > they trust you and other maintainers that you do a good and stable job. Won't
> > creating several ports/forks/whatever destroy at least part of this?
> 
> Sure. But the point is, the GPLv2 isn't exactly up for discussion. People 
> can complain all they want, but if they want to trust me, they'll take the 
> GPLv2. It's that easy.

I think there'd be a justification for licensing part of git like sparse 
is licensed, for the same reasons. It wouldn't include any of the 
interesting operations, probably, but it would be worth having a canonical 
implementation of reading and writing the data structures, so other 
implementations don't screw that up. I wouldn't like to have someone write 
a version that generated subtly corrupt git objects that it accepts along 
with proper objects, such that we have to work around the breakage. It's a 
bit less likely to happen if there's no licensing reason not to use the 
same code.

	-Daniel
*This .sig left intentionally blank*

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Daniel Barkalow wrote:

> On Thu, 27 Jul 2006, Linus Torvalds wrote:
> 
> > On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> > > 
> > > I think that part of the anwser for question "Why do people use GIT?" is that
> > > they trust you and other maintainers that you do a good and stable job. Won't
> > > creating several ports/forks/whatever destroy at least part of this?
> > 
> > Sure. But the point is, the GPLv2 isn't exactly up for discussion. People 
> > can complain all they want, but if they want to trust me, they'll take the 
> > GPLv2. It's that easy.
> 
> I think there'd be a justification for licensing part of git like sparse 
> is licensed, for the same reasons. It wouldn't include any of the 
> interesting operations, probably, but it would be worth having a canonical 
> implementation of reading and writing the data structures, so other 
> implementations don't screw that up.

You could probably even get away just copying these I/O operations, 
because there is obviously no other way to do it. Ergo, no enforcable 
copyright on those code sections.

Ciao,
Dscho

Re: Licensing and the library version of git

[David Lang]

On Thu, 27 Jul 2006, Linus Torvalds wrote:

> (*) I will, in fact, claim that the difference between a bad programmer
> and a good one is whether he considers his code or his data structures
> more important. Bad programmers worry about the code. Good programmers
> worry about data structures and their relationships.

personally I'd add to this that after the data structures are defined and you 
turn to the code the API is significantly more important then the code itself.

David Lang

Re: Licensing and the library version of git

[Linus Torvalds]

On Thu, 27 Jul 2006, David Lang wrote:
> 
> > (*) I will, in fact, claim that the difference between a bad programmer
> > and a good one is whether he considers his code or his data structures
> > more important. Bad programmers worry about the code. Good programmers
> > worry about data structures and their relationships.
> 
> personally I'd add to this that after the data structures are defined and you
> turn to the code the API is significantly more important then the code itself.

I think people sometimes put too much emphasis on ABI's. 

Sure, if you're depending on a library, the ABI is supremely important. 
But I literally believe that one of the things that makes open source 
technically superior to most other projects is the fact that ABI's can be 
changed more easily, and sometimes at all.

If you have good data structures, the ABI's are largely irrelevant, and if 
you have a problem with an existing ABI, you can just write a new 
entrypoint instead (and leave the old ABI alone).

On the other hand, if you have bad datastructures, the ABI often reflects 
that, and having the balls to say that your ABI's are broken and need to 
be re-done in order to fix the data structures is _very_ important. 
Otherwise you'll never be able to fix anything.

So I think that ABI's are often _way_ overhyped. If they are good, 
everybody is happy. But if the interfaces are bad, you had better be 
willing to just say "screw the ABI" and just fix it.

Now, that doesn't mean that you should change ABI's on a whim, and 
regardless of any other issues, your user base is always important. But I 
don't think ABI's are, or should be, "sacred".

For example, one thing git did early on was to just admit that some ABI's 
are horribly horribly bad. For example, the CVS "annotate" ABI is just a 
mistake, and trying to support that would just have held git back from 
realizing that you can be so much more.

That may not be a "Application Binary Interface" kind of ABI, but it's an 
interface, and it's exactly the same thing - sometimes you just have to 
have the cajones to say "screw that, we'll be so much better if we can 
change the interface".

		Linus

Re: Licensing and the library version of git

[David Lang]

On Thu, 27 Jul 2006, Linus Torvalds wrote:

> On Thu, 27 Jul 2006, David Lang wrote:
>>
>>> (*) I will, in fact, claim that the difference between a bad programmer
>>> and a good one is whether he considers his code or his data structures
>>> more important. Bad programmers worry about the code. Good programmers
>>> worry about data structures and their relationships.
>>
>> personally I'd add to this that after the data structures are defined and you
>> turn to the code the API is significantly more important then the code itself.
>
> I think people sometimes put too much emphasis on ABI's.

I was careful to say aPi, not aBi :-)

> Sure, if you're depending on a library, the ABI is supremely important.
> But I literally believe that one of the things that makes open source
> technically superior to most other projects is the fact that ABI's can be
> changed more easily, and sometimes at all.

very true

> If you have good data structures, the ABI's are largely irrelevant, and if
> you have a problem with an existing ABI, you can just write a new
> entrypoint instead (and leave the old ABI alone).
>
> On the other hand, if you have bad datastructures, the ABI often reflects
> that, and having the balls to say that your ABI's are broken and need to
> be re-done in order to fix the data structures is _very_ important.
> Otherwise you'll never be able to fix anything.

however it's possible to have a good data structure and a bad API. I'm just 
emphisising the API over the 'elegance', etc of the code that implements it.

> So I think that ABI's are often _way_ overhyped. If they are good,
> everybody is happy. But if the interfaces are bad, you had better be
> willing to just say "screw the ABI" and just fix it.
>
> Now, that doesn't mean that you should change ABI's on a whim, and
> regardless of any other issues, your user base is always important. But I
> don't think ABI's are, or should be, "sacred".

I'm not meaning to imply in any way that API's are sacred, just that they are 
very important and deserve a lot of thought before implementation.

David Lang

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi

On Thu, 27 Jul 2006, David Lang wrote:

> On Thu, 27 Jul 2006, Linus Torvalds wrote:
> 
> > On Thu, 27 Jul 2006, David Lang wrote:
> > > 
> > > > (*) I will, in fact, claim that the difference between a bad programmer
> > > > and a good one is whether he considers his code or his data structures
> > > > more important. Bad programmers worry about the code. Good programmers
> > > > worry about data structures and their relationships.
> > > 
> > > personally I'd add to this that after the data structures are defined and
> > > you
> > > turn to the code the API is significantly more important then the code
> > > itself.
> > 
> > I think people sometimes put too much emphasis on ABI's.
> 
> I was careful to say aPi, not aBi :-)

All Linus said about ABIs is true for APIs, too. The only difference 
between the two is, that people depend on the sacredness of ABIs even more 
than on APIs.

Ciao,
Dscho

Re: Licensing and the library version of git

[Anand Kumria]

On Thu, 27 Jul 2006 12:11:00 -0400, Jon Smirl wrote:

> On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
>> > You may like trying to force GPL onto the app but many apps are
>> > stuck with the license they have and can't be changed since there is
>> > no way to contact the original developers.
>>
>> At this point, git-shortlog lists exactly 200 people (at least entries
>> like Unknown or No name are all linux@horizon.com ;-).
> 
> Inability to integrate with Microsoft Visual Studio is going to have a
> lot of impact on the cross platform use of git.  

Could you stop with the histrionics please?

> Is a conscious
> decision being made to stop this integration or is this just unplanned
> side effect of the original license? If this is an unplanned side
> effect, the quicker we move, the easier it is to fix.

So, using CVSNT (a GPL'd SCCI provider) and git-cvsserver would be a way
to continue.  I'm assuming that the primary functionality they want via
their IDE is checkout/diff/commit/log.

Quite a lot of Windows developers have no problems using multiple tools
for things, I'd assume they would also be able to use any existent port
of git (to Windows) to do the esoteric things like branching/bisect/etc.

Anand

Re: Licensing and the library version of git

[Jon Smirl]

On 7/27/06, Anand Kumria <wildfire@progsoc.org> wrote:
> On Thu, 27 Jul 2006 12:11:00 -0400, Jon Smirl wrote:
>
> > On 7/27/06, Petr Baudis <pasky@suse.cz> wrote:
> >> > You may like trying to force GPL onto the app but many apps are
> >> > stuck with the license they have and can't be changed since there is
> >> > no way to contact the original developers.
> >>
> >> At this point, git-shortlog lists exactly 200 people (at least entries
> >> like Unknown or No name are all linux@horizon.com ;-).
> >
> > Inability to integrate with Microsoft Visual Studio is going to have a
> > lot of impact on the cross platform use of git.
>
> Could you stop with the histrionics please?

It is usually wise not to make comments like this, they don't help in
building the community.

> > Is a conscious
> > decision being made to stop this integration or is this just unplanned
> > side effect of the original license? If this is an unplanned side
> > effect, the quicker we move, the easier it is to fix.
>
> So, using CVSNT (a GPL'd SCCI provider) and git-cvsserver would be a way
> to continue.  I'm assuming that the primary functionality they want via
> their IDE is checkout/diff/commit/log.

Now, that's a great strategy. Tell the large project you are
interested in switching off from CVS to git that they need to run a
CVS emulation gateway forever. I don't think a switch has much of a
chance of happening.


> Quite a lot of Windows developers have no problems using multiple tools
> for things, I'd assume they would also be able to use any existent port
> of git (to Windows) to do the esoteric things like branching/bisect/etc.
>
> Anand
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Jon Smirl wrote:

> On 7/27/06, Anand Kumria <wildfire@progsoc.org> wrote:
>
> > So, using CVSNT (a GPL'd SCCI provider) and git-cvsserver would be a way
> > to continue.  I'm assuming that the primary functionality they want via
> > their IDE is checkout/diff/commit/log.
> 
> Now, that's a great strategy. Tell the large project you are
> interested in switching off from CVS to git that they need to run a
> CVS emulation gateway forever. I don't think a switch has much of a
> chance of happening.

Oh, but it has!

The beautiful thing is that you can change to git _without_ changing all 
client software! Just to a git-cvsimport, switch, and some might not even 
notice that the server has changed behind their back.

And then, you can phase out CVS slowly.

BTW have you worked with MSVC's integrated source control? In every single 
case where I had to work with MSVC, I found I'm way faster with external 
tools (and it did not matter if the SCM was Visual Source Safe, CVS or 
PVCS). I know that my colleagues found the same.

BTW2 I agree that some deciding people would make MSVC integration a 
premise for migration to Git. So, why don't you give it a try? (I do not 
have a working MSVC setup, or I would help you.)

Ciao,
Dscho

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Jon Smirl wrote:

> On 7/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> > 
> > On Thu, 27 Jul 2006, Petr Baudis wrote:
> > 
> > > And I didn't even get to discussing whether LGPL is actually desirable
> > > for Git.
> > 
> > ... or whether it is neccessary for an Eclipse-plugin to something else
> > than GPL.
> 
> Eclipse is not licensed GPL.

We are talking about Eclipse _plugins_ here. Often (especially when the 
deciding people have $$ in their eyes), plugins have less restrictions 
(for example, WSAD would not be possible if _all_ extensions to Eclipse 
would have to be CPL).

Ciao,
Dscho

Re: Licensing and the library version of git

[Petr Baudis]

  Hi,

Dear diary, on Thu, Jul 27, 2006 at 04:04:11PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Thu, 27 Jul 2006, Jon Smirl wrote:
> 
> > On 7/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > ... or whether it is neccessary for an Eclipse-plugin to something else
> > > than GPL.
> > 
> > Eclipse is not licensed GPL.
> 
> We are talking about Eclipse _plugins_ here. Often (especially when the 
> deciding people have $$ in their eyes), plugins have less restrictions 
> (for example, WSAD would not be possible if _all_ extensions to Eclipse 
> would have to be CPL).

  I concur. IANAL but from my understanding is that GPL requires just
the work and its derivatives to be free. So it's a matter of the
derivatives chain; if you write the plugin, does Eclipse become its
derivative work? Well, the derivation went the other way around, so
the plugin is derivative work of Git and possibly Eclipse. So AFAICS the
only possible clash that _might_ happen is if Git requires CVS and
Eclipse requires some other licence.

  Too bad for Eclipse's GPL-incompatible viral licence...

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Licensing and the library version of git

[Petr Baudis]

Dear diary, on Thu, Jul 27, 2006 at 07:20:47PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> only possible clash that _might_ happen is if Git requires CVS and
                                                             ^^^

  Er, GPL! *blush*

  That said, Git still requires RCS for the merge operation. Any plans
to finally switch to diff3 and toss out another useless dependency?

  *blush for shameless plug*

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Licensing and the library version of git

[Linus Torvalds]

On Thu, 27 Jul 2006, Petr Baudis wrote:
> 
>   That said, Git still requires RCS for the merge operation. Any plans
> to finally switch to diff3 and toss out another useless dependency?

If libxdiff ever gets a real 3-way merge, I think we'd do it in a 
heartbeat.

Right now it has a function called "xdl_merge3()", but it doesn't actually 
have anythign to do with a real merge:

  "The function works by creating a differential between mmfo and mmf2 and
   by applying the resulting patch to mmf1"

so it's really just a "diff + patch".

I asked Davide about it some time ago, and I think he said that he'd like 
to do it properly, but it's always been on his back-burner and that he 
didn't foresee that changing in the immediate future..

So we can hope. Or somebody who knows the algorithms could just implement 
it and send it to both us and Davide (libxdiff _is_ LGPL, btw).

		Linus

Re: Licensing and the library version of git

[Wolfgang Denk]

In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
>
> I see that someone is already writing a pure Java version which will
> work around the GPL problem assuming the Java version is released
> under a compatible license.

... and assuming it is a clean-room  implementation  which  does  not
borrow from the GPL code.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Be careful what you wish for. You never know who will be listening.
                                      - Terry Pratchett, _Soul Music_

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Wolfgang Denk wrote:

> In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
> >
> > I see that someone is already writing a pure Java version which will
> > work around the GPL problem assuming the Java version is released
> > under a compatible license.
> 
> ... and assuming it is a clean-room  implementation  which  does  not
> borrow from the GPL code.

>From a standpoint of copyright (which the GPL relies on), this is not 
possible: you cannot include C code into Java. And if it is _translated_ 
from C into Java, it is not copyrighted any more.

Ciao,
Dscho

Re: Licensing and the library version of git

[Petr Baudis]

  Hi,

Dear diary, on Thu, Jul 27, 2006 at 10:39:55PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> >From a standpoint of copyright (which the GPL relies on), this is not 
> possible: you cannot include C code into Java. And if it is _translated_ 
> from C into Java, it is not copyrighted any more.

  now that's a pretty strong statement - did a lawyer tell you that?
(Lawyer in what country? Germany?) Because copyrights are generally
retained over translations, otherwise I could freely publish
e.g. Czech translation of someone else's English book without any
permissions and such, which is obviously not the case.

  There has been actually similar issue with OpenTTD - it was created by
translating Transport Tycoon Deluxe assembly to C without permission of
original TTD copyright owner (not that anyone actually knows for sure
who that is, after series of company mergers and buyouts). I don't think
anyone consulted a lawyer about legality of that either but I believe
that most people agree that this is basically illegal (but most likely,
noone will ever sue, or care at all).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Petr Baudis wrote:

> Dear diary, on Thu, Jul 27, 2006 at 10:39:55PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > >From a standpoint of copyright (which the GPL relies on), this is not 
> > possible: you cannot include C code into Java. And if it is _translated_ 
> > from C into Java, it is not copyrighted any more.
> 
>   now that's a pretty strong statement - did a lawyer tell you that?

<politics>
No. And I hate the fact that more and more people are actually accepting 
the idea of being dictated how they should live by lawyers.

If a law is not clear to a layman, it should not be enforcable.
</politics>

> (Lawyer in what country? Germany?) Because copyrights are generally
> retained over translations, otherwise I could freely publish
> e.g. Czech translation of someone else's English book without any
> permissions and such, which is obviously not the case.

<message="I am not a lawyer... sh1t, I am disgusted by those">
The bigger problem is to _prove_ that it is a translation. It is much 
easier with a 300-page book you translated from English into Czech.

It is almost impossible to prove something was copied if the source 
language is a procedural computer language, and the target language is an 
object-oriented computer language. Given the technical abilities of 
judges, I even doubt that the act of the translation would _not_ be deemed 
a non-literal transformation of the source code (and thus not be a 
copyright case).
</message>

>   There has been actually similar issue with OpenTTD - it was created by
> translating Transport Tycoon Deluxe assembly to C without permission of
> original TTD copyright owner (not that anyone actually knows for sure
> who that is, after series of company mergers and buyouts). I don't think
> anyone consulted a lawyer about legality of that either but I believe
> that most people agree that this is basically illegal (but most likely,
> noone will ever sue, or care at all).

<politics again=true>
Let's be honest: lawyers will only be interested in the money they get. 
They will not care one wit about what is right or wrong: just look in some 
newspaper of your choice. This is a sad fact about our world (but there is 
a remedy: look into the Hitchhiker's guide to the galaxy).

The consequence is: no lawyer will properly defend the work of open source 
people, since they tend to be poor (well, at least not rich). You just 
cannot make much money by being nice.
</politics>

Ciao,
Dscho

Re: Licensing and the library version of git

[Wolfgang Denk]

In message <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de> you wrote:
> 
> > ... and assuming it is a clean-room  implementation  which  does  not
> > borrow from the GPL code.
> 
> >From a standpoint of copyright (which the GPL relies on), this is not 
> possible: you cannot include C code into Java. And if it is _translated_ 
> from C into Java, it is not copyrighted any more.

Gulp. What have  you  been  smoking  lately?  Your  understanding  of
copyright (and of the GPL) is fundamentally broken.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Mr. Cole's Axiom:
        The sum of the intelligence on the planet is a constant;
        the population is growing.

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Wolfgang Denk wrote:

> In message <Pine.LNX.4.63.0607272239050.29667@wbgn013.biozentrum.uni-wuerzburg.de> you wrote:
> > 
> > > ... and assuming it is a clean-room  implementation  which  does  not
> > > borrow from the GPL code.
> > 
> > >From a standpoint of copyright (which the GPL relies on), this is not 
> > possible: you cannot include C code into Java. And if it is _translated_ 
> > from C into Java, it is not copyrighted any more.
> 
> Gulp. What have  you  been  smoking  lately?

Nothing. I am a non-smoker. Maybe that is my problem?

> Your understanding of copyright (and of the GPL) is fundamentally 
> broken.

You can read an article. And you can publish the contents in your own 
words (you do not violate copyright by that). That is a fact.

And I do not buy into your "(and of the GPL)" thing. Either I get the 
copyright, which the GPL is based on, or I don't get the copyright (but 
still get that the GPL is based on it).

Ciao,
Dscho

Re: Licensing and the library version of git

[Linus Torvalds]

On Thu, 27 Jul 2006, Johannes Schindelin wrote:
> 
> From a standpoint of copyright (which the GPL relies on), this is not 
> possible: you cannot include C code into Java. And if it is _translated_ 
> from C into Java, it is not copyrighted any more.

That is definitely not true. Translation does not take away anything from 
the copyright. If I write a book in English, and you translate it to 
German, _I_ remain the copyright holder, and you need my permission to 
distribute the result. The fact that you translated it means nothing, and 
you don't own it as a result.

Similarly, the fact that I and others hold the copyright on the source 
code very much means that we also hold the copyright on any binaries you 
"translate" that source code into, and the only thing that gives you a 
right to distribute those binaries is not the translation phase, but the 
fact that the GPLv2 allows you to distribute binaries (with certain 
requirements, of course).

Now, on the other hand it's certainly true that certain elements are 
potentially uncopyrightable. If there is effectively only one sane or 
common way to actually write a git object to disk, the fact that your code 
ends up looking very similar in Java to the way it is done in the original 
C does not imply any copyright problems at all.

But that doesn't mean that you can take the C code and just rewrite it as 
Java - it was still copyright protected. It just means that if your Java 
code ends up looking like the C code, you can explain why it happened.

Now, some things have _no_ copyright protection at all, at least in 
certain areas. Facts and things that did not involve any artistic 
expression at all are simply not copyrightable. So if you list the first 
million digits of PI, you can't complain if somebody copies them, for 
example.

(But in some places, you can apparently claim that you "spent effort" on 
gathering those digits of PI, and that others would have to spend that 
same effort rather than copy your end result. I suspect that's a very weak 
argument, but I suspect that there have been worse arguments made in front 
of a judge in, say, places like Utah, to pick a random one).

And as usual, tech people talking legal issues is not very sane. So talk 
to a lawyer if you really care.

			Linus

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Linus Torvalds wrote:

> And as usual, tech people talking legal issues is not very sane. So talk 
> to a lawyer if you really care.

Amen.

And I will not talk to a lawyer today: I had a lovely day, and I don't 
want to spoil it.

Ciao,
Dscho

Re: Licensing and the library version of git

[Shawn Pearce]

Wolfgang Denk <wd@denx.de> wrote:
> In message <9e4733910607270554p5622ee20ida8c264cf3122500@mail.gmail.com> you wrote:
> >
> > I see that someone is already writing a pure Java version which will
> > work around the GPL problem assuming the Java version is released
> > under a compatible license.
> 
> ... and assuming it is a clean-room  implementation  which  does  not
> borrow from the GPL code.

Heh.  This is actually possibly a problem.

I'm the person developing the Java implementation.

I've seen some of the core GIT code.  The reflog implementation is my
most notable contribution, but I've seen other things in there too.

Most of the Java code is quite different from the C code; the
largest common component is the pack delta decompressor.  I ran it
past Nico as he wrote the C version. He didn't seem to think that
the Java version was derived from the C version.

The issue there really was that the pack file format wasn't
completely documented external from the code (I actually found a
bug in the docs and submitted a patch to correct it) and the delta
format is definately not documented so I had to dig around in the
C code to figure it out.  On the other hand the commit format,
tree format and the loose object header were all clearly self
describing so I didn't need to go digging through the source to
figure out how to parse (or generate) them.

So yes, the Java implementation is derived from the C
(GPL'd!) implementation, but also no, its not...

I think its going to really just come down to a list consensus.
If Linus, Junio, Nico, et.al. think that my Java version is too
derived from the C GPL'd implementation to be released under any
license other than the GPL then I'll probably just abandon the code
line entirely, as the GPL is incompatible with the Sun JRE runtime
lirbary.  On the other hand its probably going to be released under
the IBM Common Public License or the Apache License.

-- 
Shawn.

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Fri, 28 Jul 2006, Shawn Pearce wrote:

> [...] as the GPL is incompatible with the Sun JRE runtime lirbary.

This is not true. You can legally write and run GPLed software on the JRE 
runtime library.

BTW I found an Eclipse plugin which is GPLed:

http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-651.html

Ciao,
Dscho

Re: Licensing and the library version of git

[Shawn Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
> 
> On Fri, 28 Jul 2006, Shawn Pearce wrote:
> 
> > [...] as the GPL is incompatible with the Sun JRE runtime lirbary.
> 
> This is not true. You can legally write and run GPLed software on the JRE 
> runtime library.
> 
> BTW I found an Eclipse plugin which is GPLed:
> 
> http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-651.html

Thanks.  I did a little research on it myself after reading your
email. I turned up the following two pages from the FSF:

  http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat
  http://www.gnu.org/licenses/lgpl-java.html

Both suggest that I can license everything under the GPL but provide
exclusions to allow users to run the code against its dependencies
which aren't GPL'd:

  - the end-user may 'link' the code against any Java runtime library
    of their choice;

  - the end-user may 'link' the code against any Eclipse platform
    or derivative of their choice;

So given that I'm seriously considering changing the license to
GPLv2 for the next version.

-- 
Shawn.

Re: Licensing and the library version of git

[Jon Smirl]

On 7/28/06, Shawn Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Fri, 28 Jul 2006, Shawn Pearce wrote:
> >
> > > [...] as the GPL is incompatible with the Sun JRE runtime lirbary.
> >
> > This is not true. You can legally write and run GPLed software on the JRE
> > runtime library.
> >
> > BTW I found an Eclipse plugin which is GPLed:
> >
> > http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-651.html
>
> Thanks.  I did a little research on it myself after reading your
> email. I turned up the following two pages from the FSF:
>
>   http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat
>   http://www.gnu.org/licenses/lgpl-java.html
>
> Both suggest that I can license everything under the GPL but provide
> exclusions to allow users to run the code against its dependencies
> which aren't GPL'd:
>
>   - the end-user may 'link' the code against any Java runtime library
>     of their choice;
>
>   - the end-user may 'link' the code against any Eclipse platform
>     or derivative of their choice;
>
> So given that I'm seriously considering changing the license to
> GPLv2 for the next version.

Using the GPL plus your own exceptions creates another new license
which is a pain for everyone involved. Why not just use the standard
version with exceptions, the LGPL. The LGPL already allows the two
exceptions listed.

I don't believe there is any legal way to link GPL code into a Java
app since there are no free Java runtimes. This includes both C
libraries and Java code.

GPL is great for a kernel, but it runs into difficulties in user space
where there are hundreds of historical licenses that it can't mix
with. The viral concept only works if the target app has the ability
to relicense which is usually impossible for existing code.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Licensing and the library version of git

[Johannes Schindelin]

Hi,

On Sat, 29 Jul 2006, Jon Smirl wrote:

> I don't believe there is any legal way to link GPL code into a Java
> app since there are no free Java runtimes.

First, there are quite a few free Java runtimes; you did not really try to 
find one, right?

Second, since the Java runtime can be likened to the libc, all 
de-restrictions about system libraries should hold for Java, too.

Hth,
Dscho