Welcome, Guest. Please login or register.

Author Topic: GPL RTG driver information available  (Read 15604 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline kolla

Re: GPL RTG driver information available
« Reply #59 from previous page: May 18, 2016, 11:22:21 PM »
We are well outside US jurisdiction here.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline HeiroglyphTopic starter

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show only replies by Heiroglyph
Re: GPL RTG driver information available
« Reply #60 on: May 19, 2016, 01:26:24 AM »
Quote from: kolla;808744
We are well outside US jurisdiction here.


Yeah about that... I'm deep in the heart of Texas where patent trolls drag their victims for the easy kill.

I did manage to contact someone who can help clarify the issue.

Fingers crossed that I get a reply so this issue can be put to rest.
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show only replies by grond
Re: GPL RTG driver information available
« Reply #61 on: May 19, 2016, 06:50:26 AM »
Linde, cloning an entire API is a case of anti competitive behaviour. There is no competition here and no API has been cloned. A driver was written making use of an undocumented API, that's all. Clearly unrelated.
 

Offline Fats

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 672
    • Show only replies by Fats
Re: GPL RTG driver information available
« Reply #62 on: May 19, 2016, 09:54:23 PM »
Quote from: Heiroglyph;808680
I think GPL might accomplish exactly what I wanted, preventing closed source derivatives of the work.

LGPL leaves the loophole of putting all the working parts into a separate, closed library.

Using GPL forces all programs using the library to also be GPL that is the reason why a GPL library can't be included in AROS but a LGPL one can.
« Last Edit: May 19, 2016, 09:57:21 PM by Fats »
Trust me...                                              I know what I\'m doing
 

Offline HeiroglyphTopic starter

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show only replies by Heiroglyph
Re: GPL RTG driver information available
« Reply #63 on: May 20, 2016, 12:07:47 AM »
Quote from: Fats;808795
Using GPL forces all programs using the library to also be GPL that is the reason why a GPL library can't be included in AROS but a LGPL one can.

I think this is an odd case because of the clause I stated earlier that allows you to link to system libraries that are not GPL.

Example 1:
GPL app on windows. It has to link to the typical Win32 dll's to do anything useful. That's allowed because of this clause.

Example 2:
GPL app on NetBSD.
It has to link to the BSD licensed NetBSD code.
It also has to link to the XFree86 or MIT licensed X server to display the UI.

Example 3:
GPL kernel video driver on Linux.
It is loaded by the XFree86 or MIT licensed X server.

These are very relevant to the split between AOS, P96 and my driver.

What I wanted to prevent was any user linking to a closed library to hide the inner workings of the driver.

Doing that would essentially make the driver closed source and future users could not fix it, understand the hardware or learn from how it was written.

Edit: The other benefit of GPL is that you can take huge chunks of code from existing, well tested Linux drivers without license issues.
« Last Edit: May 20, 2016, 12:14:29 AM by Heiroglyph »
 

Offline deadwood

  • Jr. Member
  • **
  • Join Date: Nov 2008
  • Posts: 88
    • Show only replies by deadwood
Re: GPL RTG driver information available
« Reply #64 on: May 20, 2016, 05:59:42 AM »
@Heiroglyph

The "system libraries" provision in GPL is not symmetrical. You can have a GPL application use non-GPL-compatible system library, but you cannot have a GPL plugin into a non-GPL-compatible system library (driver is essentially a plugin).

http://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF

The linked text says that you add an exception to GPL license to allow using your GPL plugin with non-GPL-compatible program. This is allowed of course as long as you are the author of the code. This will not work if you take GPL code from Linux, because you are not the author and you cannot alter the original GPL license of Linux codes.

Cases 1) and 2) work because of system library provision. Case 3) works because Linux kernel uses a modified version of GPL where it states that doing a system call to kernel is not considered derived work:

NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the linux
 kernel) is copyrighted by me and others who actually wrote it.

If you decide to you GPL for the driver, you will be in essence violating your own license. GPL was designed to spread GPL and it was done so by people who know what they were doing. I doubt you will find holes in it. As I'm not really into forcing people into certain mind set, I prefer licenses that guarantee that extensions to my code base need to be made available, but usage of my code base does not. At the end of the day, it does not pay for a developer to maintain a fork of my codes and continuously integrate his changes with my latest version, so it makes total sense for him to contribute his changes to my code base.
 

Offline HeiroglyphTopic starter

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show only replies by Heiroglyph
Re: GPL RTG driver information available
« Reply #65 on: May 20, 2016, 06:35:11 AM »
Quote from: deadwood;808813
@Heiroglyph

The "system libraries" provision in GPL is not symmetrical. You can have a GPL application use non-GPL-compatible system library, but you cannot have a GPL plugin into a non-GPL-compatible system library (driver is essentially a plugin).

http://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF

The linked text says that you add an exception to GPL license to allow using your GPL plugin with non-GPL-compatible program. This is allowed of course as long as you are the author of the code. This will not work if you take GPL code from Linux, because you are not the author and you cannot alter the original GPL license of Linux codes.

Cases 1) and 2) work because of system library provision. Case 3) works because Linux kernel uses a modified version of GPL where it states that doing a system call to kernel is not considered derived work:

NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the linux
 kernel) is copyrighted by me and others who actually wrote it.

If you decide to you GPL for the driver, you will be in essence violating your own license. GPL was designed to spread GPL and it was done so by people who know what they were doing. I doubt you will find holes in it. As I'm not really into forcing people into certain mind set, I prefer licenses that guarantee that extensions to my code base need to be made available, but usage of my code base does not. At the end of the day, it does not pay for a developer to maintain a fork of my codes and continuously integrate his changes with my latest version, so it makes total sense for him to contribute his changes to my code base.


The more I learn, the less I know and care about licensing. As litigious as this "community" is, you unfortunately have to.

All I want is for the community to have some semblance of control over their own hardware once what little money is left dries up without a certain company yet again taking the work of another and charging for it without paying them.

Everyone just keeps paying them because there are no other options. This might help someone compete and help the community.

What do you suggest I license this as if I can get permission or rewrite it?
 

Offline nicholas

Re: GPL RTG driver information available
« Reply #66 on: May 20, 2016, 10:04:27 AM »
@Heiroglyph

Perhaps the FSF might be able to help with information on the legal aspect of things?

https://www.fsf.org/about/contact
“Een rezhim-i eshghalgar-i Quds bayad az sahneh-i ruzgar mahv shaved.” - Imam Ayatollah Sayyed  Ruhollah Khomeini
 

guest11527

  • Guest
Re: GPL RTG driver information available
« Reply #67 on: May 20, 2016, 10:29:33 AM »
Quote from: Heiroglyph;808814
What do you suggest I license this as if I can get permission or rewrite it?

Probably check with the author first what he things. I personally would probably also stay away from GPL as it is a can of worms. That's a particular one.

My suggestions: BSD is a particularly easy license. It does not have a copyleft, it basically grants access to the code under conditions "do whatever you want to do".

But probably that's not what you like, or the authors. It allows "forking as you like, usage as you like", including commercial usage, and no copyleft attached.

So another option would be to look into the family of "Creative Commons" licenses because they really have a larger "mix and match" repository where you can pick your conditions.

For example, you could use "CC ND NC", meaning its open, it cannot be forked, and commercial usage is prohibited.

Another variant is "CC BY", i.e. "do what you want, but quote the author".

So there are a couple of options you can look into.

As far as P96 is concerned, my *personal* best fit is "CC ND NC" or "CC ND NC BY". Probably even without the NC part I personally do not care much about. "ND" is something I personally consider useful if you want to ensure one single consistent repository - and that's pretty useful for end users so they don't have to pick "which version works for me", as there is only one.
 

Offline Niding

  • Hero Member
  • *****
  • Join Date: Sep 2004
  • Posts: 566
    • Show only replies by Niding
Re: GPL RTG driver information available
« Reply #68 on: May 20, 2016, 11:03:46 AM »
@Heiroglyph

I suggest you join Apollo-Team IRC channel so you can discuss it directly, in realtime with knowledgable people.

IRC Server  irc.freenode.org
Port  6667

Channel  #apollo-team

This back and forth doesnt seem very constructive.
 

Offline Gulliver

Re: GPL RTG driver information available
« Reply #69 on: May 20, 2016, 01:20:12 PM »
Things get more interesting regarding Picasso96 as days goes by:

http://eab.abime.net/showthread.php?t=82753&page=2


Post #25 is an eye opener
 

guest11527

  • Guest
Re: GPL RTG driver information available
« Reply #70 on: May 20, 2016, 01:44:08 PM »
Quote from: Gulliver;808831
Things get more interesting regarding Picasso96 as days goes by:

http://eab.abime.net/showthread.php?t=82753&page=2


Post #25 is an eye opener

No, please read on. He's talking about PicassoII, not Picasso 96. Continue to post #34.
 

Offline Linde

  • Sr. Member
  • ****
  • Join Date: Mar 2004
  • Posts: 457
    • Show only replies by Linde
    • http://hata.zor.org/
Re: GPL RTG driver information available
« Reply #71 on: May 20, 2016, 02:16:25 PM »
Quote from: deadwood;808813
The "system libraries" provision in GPL is not symmetrical. You can have a GPL application use non-GPL-compatible system library, but you cannot have a GPL plugin into a non-GPL-compatible system library (driver is essentially a plugin).


That is not completely true. You may not distribute GPL-compatible binaries as part of non GPL-distribution of software (as a plugin or linked otherwise). For example, you may not include the driver in a closed source OS distribution. You can however share just the driver, and whatever users do with it that doesn't involve redistributing it (or distributing derivative works) is perfectly fine. That is, there is nothing in the license that stops me from downloading GPL software and doing whatever I want with it on my system, as long as I am not redistributing it in a way that isn't compliant with the license.

This is how you can for example legally download GPL software, modify it to your heart's content and never share any of it. It's only when I distribute the software that the license may become an issue.
 

Offline billt

  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 910
    • Show only replies by billt
    • http://www.billtoner.net
Re: GPL RTG driver information available
« Reply #72 on: May 20, 2016, 02:28:55 PM »
Quote from: Gulliver;808831
Things get more interesting regarding Picasso96 as days goes by:

http://eab.abime.net/showthread.php?t=82753&page=2

Post #25 is an eye opener


and oosts 34 and 38 close them again.
Bill T
All Glory to the Hypnotoad!
 

Offline Gulliver

Re: GPL RTG driver information available
« Reply #73 on: May 20, 2016, 02:38:39 PM »
It seems you still dont get it:

He is offering Cybergraphics. With Cybergraphics in hand we can ditch Picasso96 into oblivion along with all its associated drama and greedy vultures.
 

Offline HeiroglyphTopic starter

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show only replies by Heiroglyph
Re: GPL RTG driver information available
« Reply #74 on: May 20, 2016, 03:08:21 PM »
Quote from: Gulliver;808838
It seems you still dont get it:

He is offering Cybergraphics. With Cybergraphics in hand we can ditch Picasso96 into oblivion along with all its associated drama and greedy vultures.


It's definitely a step in the best direction, assuming it's legitimate, because Aros has a very similar API.

The downside is trying to run CGX on most PCI boards because the closed source drivers are all for P96.

You can't use those on CGX, right? I've only used CGX once or twice over the years, so I'm not that familiar.

In addition, Elbox drivers do more than just graphics so that they can set up their DMA bounce buffers and who knows how that black box works.