IPF and Openness

All news about KryoFlux go here.
pak21
Posts: 26
Joined: Wed Feb 09, 2011 10:32 am

Re: IPF and Openness

Post by pak21 » Wed Feb 09, 2011 8:08 pm

Tuxie wrote:Wouldn't the MAME license prevent shareware emulators from using it?
Yes, but there's nothing to stop the SPS team giving shareware emulator authors a free license to use the software.

Harry
Posts: 133
Joined: Wed Feb 09, 2011 9:31 pm

Re: IPF and Openness

Post by Harry » Wed Feb 09, 2011 9:42 pm

As for dynamic linking an IPF dll with a GPL emulator, it may be worthwile to read it carefully.
An excerpt from GPLv3, Section 5 is:

" A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate." (GPLv2 contains a similar paragraph.)

As far as i understand, the ipflibrary contains eg a whole emulator of a disk controller,
is used in many (5 up to now) programs and thus qualifies as a separate and
independent work. Thus GPLed emulators might use it. But i am no lawyer, maybe
someone is more qualified to interpret that paragraph than me.

pak21
Posts: 26
Joined: Wed Feb 09, 2011 10:32 am

Re: IPF and Openness

Post by pak21 » Wed Feb 09, 2011 10:03 pm

Harry wrote:As far as i understand, the ipflibrary contains eg a whole emulator of a disk controller,
is used in many (5 up to now) programs and thus qualifies as a separate and
independent work.
Again, the FSF's lawyers would disagree with you; that clause is for the distribution of GPL code on a medium (eg a CD) with non-GPL code. A disk controller is not a program on its own.

virol
Posts: 1
Joined: Wed Feb 09, 2011 10:03 pm

Re: IPF and Openness

Post by virol » Wed Feb 09, 2011 11:20 pm

If you do go with a version of the GPL, I would hope that you choose LGPL, but this, unfortunately, won't get you the non-commercial protection you want, since it will be legally possible to write commercial software that links against the library and distribute it together. Use of the full GPL will get you non-commercial protection, since commercial entities will be quite reluctant to open up their software to match, this is true. The downside is that you'll also lose all of the non-commercial entities out there that do not use GPL.

I think the MAME license is a fine license, but I don't care much about GPL-compatibility. My main concern is that whatever you decide on should be non-viral. MAME/GPL dual license as already discussed would seem to serve both purposes. Users who desire non-viral licenses can use it under the terms of MAME, which explicitly forbids commercial use, and users who desire GPL compatibility can use it under the GPL, which makes commercial use difficult but not impossible. For maximum compatibility, you should use GPLv2 (and later, as desired), which has a very large developer community still and will likely do so into the foreseeable future. Personally, I think that preventing commercial use is ultimately more trouble than it is really worth, and a permissive license like two or three clause BSD is best, but I understand your point of view on the matter.

I did want to address something mentioned back up the thread a ways: the issue of forking and derivative works. It is absolutely vital that these be allowed. The truth of the matter is that the SPS is not likely to be an immortal institution. The very history you are dedicated to preserving, and the need for such preservation attests to the unlikeliness of this. If I cannot fork the IPF library and the SPS dies then development of the IPF library also dies. If the IPF format is to survive in the long run, it needs to be able to survive the death of the SPS as an entity in the world. It needs to be able to be taken up by other people, ported to new systems, new features added, whatever else. We cannot predict what will become necessary in the future, or what uses the format might be put to, not with certainty. This is why forks and derivatives are vital. Not because it is of any great use that I should make incompatible versions of the library in the now, but because the future is uncertain.

Harry
Posts: 133
Joined: Wed Feb 09, 2011 9:31 pm

Re: IPF and Openness

Post by Harry » Thu Feb 10, 2011 12:07 am

pak21 wrote:Again, the FSF's lawyers would disagree with you; that clause is for the distribution of GPL code on a medium (eg a CD) with non-GPL code. A disk controller is not a program on its own.
It is as much an independent program as the display drivers in the Linux kernel, and there is not only the view of the FSF. See some posts earlier. I for myself would take the risk to implement ipf support in a GPLed emulator. That the FSF would sue a GPL project for linking a commercial library would be my LEAST concern.

pak21
Posts: 26
Joined: Wed Feb 09, 2011 10:32 am

Re: IPF and Openness

Post by pak21 » Thu Feb 10, 2011 12:22 am

Harry wrote:It is as much an independent program as the display drivers in the Linux kernel
As I've said upthread, the kernel is a special case, if nothing else because of Linus's comments on the subject.
and there is not only the view of the FSF
True. However, they pay professional IP lawyers for their advice - where does yours come from?
I for myself would take the risk to implement ipf support in a GPLed emulator.
If you do so in Fuse, you may well discover that this rapidly becomes a test case (assuming you can find an ISP willing to host your infringing material).
That the FSF would sue a GPL project for linking a commercial library would be my LEAST concern.
You seem to misunderstand how this works; the FSF would not be able to sue anybody unless you violated the copyright of an FSF project. That would be fun to watch :-)

User avatar
ville9
Posts: 1
Joined: Wed Feb 02, 2011 12:11 pm

Re: IPF and Openness

Post by ville9 » Thu Feb 10, 2011 1:52 am

virol wrote:If the IPF format is to survive in the long run, it needs to be able to survive the death of the SPS as an entity in the world. It needs to be able to be taken up by other people, ported to new systems, new features added, whatever else.
That's exactly our concern. We know that it has to be open to be accepted as a preservation format. However, I don't see the point in doing derivative works when everyone can contribute to the main project.

User avatar
mr.vince
Posts: 2120
Joined: Tue Oct 05, 2010 5:48 pm

IPF and Openness

Post by mr.vince » Thu Feb 10, 2011 8:49 am

The problem is that most derivates are not made because a project is dead. Sometimes they are made by hot headed students living with mum that just need to get attention. Others again don't like what you do (we got enough of those because they can't get preservation right).

I agree, one of the reasons we make it open is that the project _might_ cease to exist. But it will be soon enough to start a fork or derivate should this ever happen.

To address the lawyer thing above: these always get paid by someone and of course they will try to support the client's vision, as far as legally possible. They will not reveal arguments against, even if there are plenty. That's how their job works. So I would not take FSF wording for set in stone.

Darkstar
Posts: 72
Joined: Thu Nov 04, 2010 7:58 pm

Re: IPF and Openness

Post by Darkstar » Thu Feb 10, 2011 9:21 am

Go with the MAME license then. It has had some testing and seems to work pretty well (i.e. they shut down some projects in the past)

You might want to consult with an open-source lawyer (or at least someone knowledgeable, like the guys behind gpl-violations.org) though

-Darkstar

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Thu Feb 10, 2011 1:47 pm

Thanks for all the comments. This is certainly a useful and productive discussion, even though non-commercial licences are looking to be so thin on the ground. Dual-licensing is not something that we had considered before, so that is an interesting direction to consider. We still need to bash out some details on that before we would be happy with it though, but that doesn't stop us doing something now and move to dual-licensing model later.

I'll put out one minor off-topic point. Although I didn't think it really suitable for the IPF library, I have always been generally pro-GPL (as the other SPS guys can attest), and indeed I have a little code published under it. However, I do think that some (hopefully a very small number) of its advocates do it a disservice by the methods of their evangelism. It seems many projects give up and are assimilated eventually, so perhaps coming on strongly is just a strategy that works. I'm sure this subject has been done to death, but if you are trying to convince, it seems to me to be far better to advertise the strengths of something rather than weald it around like a mallet. This is, of course, not a good argument against using the GPL.

Anyway, just for the record, I have found one other licence that has been used in least one popular product (Ghostscript) that has limits on commercial use, so probably needs consideration. The Aladdin Free Public License (AFPL), which is derived from (but of course incompatible with) the GPL. I don't have time to look at it properly now, so I'll just throw it in here for now.
http://en.wikipedia.org/wiki/Aladdin_Fr ... ic_License

Post Reply